Open e-five256 opened 6 months ago
This issue is stale because it has been open 50 days with no activity. Remove stale label or comment or this will be closed in 6 days.
I think we do need it and we have to create the users right away. Simply because we have to reserve the username. What would happen when the user then already exists when an admin approves an account...
Additionally I think that the solution in the user
table is just so much easier :D
I think we do need it and we have to create the users right away. Simply because we have to reserve the username. What would happen when the user then already exists when an admin approves an account... Additionally I think that the solution in the
user
table is just so much easier :D
OK fine, but in that case an additional column should be present that it isn't active
yet. So when approval feature is disable the users are active by default. And otherwise the active column should be false, and only set to true after approval?
Then we also need to make sure that the user isn't listed when active
(or whatever the column name will be) is false. And the user can't login if active
is false. etc.
Is your feature request related to a problem? Please describe.
Right now instance owners still are lacking some measures to fight back against spam waves. One that may help is adding an option for account creation to require admin/global mod (maybe) approval before the account can be used
Describe the solution you'd like
We might want to investigate how other platforms do this. One major consideration is, if enabled, should accounts be made (and the address for that account name burned)? Or should the accounts be held in a separate state until admin approval, at which point they are created and the fediverse can find them.
Assuming we don't want to create the accounts in a way that uses the address forever before approval:
users_awaiting_approval
with columns of theusername, hashed_password, email
etc that are required to create an accountpublic.user
entry, email the userIf instead we don't care if the username is burned, another possible implementation is
public.user
such asrequires_approval = true
true
requires_approval
istrue
. New index onwhere requires_approval is true
to make the query fastDescribe alternatives you've considered
There might be other options to curtail spam that are lower hanging fruit, if people can think of them. We could also just do something like an admin option to automatically ban users on registration, so admins could then unban as a form of "approval". The flow would be confusing for users, but it's all tech that exists today so would be faster to implement