Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternative Way to Approve Accounts #1276

Open
TomatDividedBy0 opened this issue Aug 9, 2021 · 5 comments
Open

Alternative Way to Approve Accounts #1276

TomatDividedBy0 opened this issue Aug 9, 2021 · 5 comments
Labels
deployment enhancement New feature or request

Comments

@TomatDividedBy0
Copy link

The Fediverse suffers from a really bad botspam problem, so I understand why the main instance uses manual approval. However, when I introduce people to the site, that part tends to throw them off. I wonder if we could have an un-approved account still able to set up their profile but the profile remains invisible to the local/public timelines until a moderator verifies the account. This'd give people a window of time in which they can focus on setting up their account/libraries (usually a process which takes a few hours) while they wait for approval from the staff.

@mouse-reeve
Copy link
Member

I actually just switched the main instance to open registration a day or two ago! I wanted to do it quietly so there wouldn't be a spike in traffic.

Right now there are a few ways you can configure registration:

  • Totally open, no approval or verification required
  • Open, users have to confirm their email with a link automatically sent
  • Invite-only, users can put their email in and have to wait for mod approval to create an account
  • Closed, there's no way to register through the app, but admins can manually give out invitation links

My qualm about creating a pending state where users can add books and set up their profile is that it could create situations where someone has put a lot of work into loading data and then not be approved for whatever reason, which I feel like would be frustrating for the user.

@mouse-reeve mouse-reeve added deployment enhancement New feature or request labels Aug 9, 2021
@TomatDividedBy0
Copy link
Author

One of the ideas which cropped up when Lemmy was coming up with a plan was to allow for invite-links in conjunction with a manual approval-process.

Maybe having our manual-approval system include invite links would work as an idea.

@mouse-reeve
Copy link
Member

Can you clarify what you mean by combining manual approval with invite links? What might that look like concretely as a sign up flow?

Right now, if you are set up to manually approve registrations, approving the registration means automatically sending a single-use invite link to the requester. So on a technical level, they're already related. But I'm not sure that's what you mean.

@TomatDividedBy0
Copy link
Author

Can you clarify what you mean by combining manual approval with invite links? What might that look like concretely as a sign up flow?

Right now, if you are set up to manually approve registrations, approving the registration means automatically sending a single-use invite link to the requester. So on a technical level, they're already related. But I'm not sure that's what you mean.

As in, let us say an instance has manual approval enabled. This can be bypassed should an already-approved user provide a generated registration URL to someone who is looking to sign up. This'd allow us to avoid spam while also making it so people we want to recommend the site to don't have to wait. Which that latter part, from what I've seen has been a turnoff for federated sites for people.

Think like how invites on Discord work. You invite your friend, and admins are able to deal with the flow much easier when every invite is visibly tied to a specific user.

@mouse-reeve
Copy link
Member

Ah thank you. So every user would have invites, and you can tell who invited whom.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deployment enhancement New feature or request
2 participants