Users who request already-taken usernames should be invited to request a new username

[holmesworcester]

Right now a user picks their username without knowing anything about what usernames have already been registered. This will mean they pick duplicate, already-taken usernames sometimes.

Here's what should happen in this case:

1. When users sync the set of names, and see that the name they requested is already taken by another user, they will get a "username taken" message and have a chance to choose a new name. They should not need a response from the community owner to tell them their name is taken.
2. Once they have requested a new name, they will use that new name in an unregistered way until the community owner registers them.
3. Once they know the set of users in the community, the "choose username" screen should validate whether the username has been taken.
4. If somehow two users simultaneously register the same name, the same thing should happen. Whoever is not successful should notice that their name is registered by somebody else and they should see the "choose username" window again.

Notes:

• If the username they've chosen is already in use, it will show a "duplicate" warning while it is unregistered, whenever it is used, as per Warn user of duplicate unregistered names #1559
• The registrar can simply ignore invalid username requests, because users learn their username is taken from the list of registered users.
• One result of this design is that if they choose a duplicate username, they should see the "username taken" screen as soon as they join the community, because they will see that the name is in use by another user.
• The "@user has joined Community" message will still display with their chosen name, as soon as they join the community (not when they are registered)
• No message will appear when they are registered. Their username's status will simply change.
• At some point we should encrypt the registration request so that someone can't frontrun it. Created an issue in Encrypt registration request so that malicious users can't frontrun it #1715

Designs for "username taken" screens:

https://www.figma.com/file/TV9pF84Ob8pLYRLu83gNol/Joining-when-owner-is-offline?type=design&node-id=311-6116&mode=design&t=zJWpEmDpd1LSWwEO-4

[holmesworcester]

@EmiM @kowalski @Kacper-RF @vinkabuki what do you think of the above? Does this make sense? Can you think of a simpler solution?

A better way to do this flow would be to let users change their names whenever they want by requesting names, and have this exist in the user's profile or settings.

Then "username taken" could just be an alert that takes people to the standard flow for requesting a new name, but we could test changing names separately from the "duplicate names" case. Is it better to do it this way now? It does introduce more screens and more complexity, but it's probably easier to test.

[kowalski]

Sounds about right to me, but lets keep in mind:

1. That it can take a while for a new user to sync the list of existing users, so there may be races involved

2. That we want to save registration requests to orbitdb. Incorrect requests would still exist in there which opens us up to a simple dos attack (by making the list of requests very long). We may mitagate this later down the line, lets just not forget

[holmesworcester]

That we want to save registration requests to orbitdb. Incorrect requests would still exist in there which opens us up to a simple dos attack (by making the list of requests very long). We may mitagate this later down the line, lets just not forget

Created #1720

That it can take a while for a new user to sync the list of existing users, so there may be races involved

Are there any cases we're missing here that could come up in a race condition?

[EmiM]

@holmesworcester I don't see a definite decisions here.
Please tell me if I understand this correctly:

• Unregistered user joins.
• At some point the app synchronizes certificates, turns out that the username is taken
• The "Username taken" modal with form is displayed as soon as the app knows about duplicated username. Is it displayed once? On each app launch?
• User can close it but the username can be changed in settings at any time (user should be informed about that somehow)
• Username can be changed only if there is a duplicate (?)

My opinion is that it is a good idea to allow user to change username in user's profile or settings - so whenever they want - and not only when the modal appears.

Worst case scenario (unfortunate timing with connecting/disconnecting/owner being available) user can be asked to change username multiple times.

[holmesworcester]

Please tell me if I understand this correctly

Yes you do!

Is it displayed once? On each app launch?

Let's do it once for now.

My opinion is that it is a good idea to allow user to change username in user's profile or settings - so whenever they want - and not only when the modal appears.

I agree, but we don't have designs for that yet, and I have created a separate issue. #1716. I think it's fine to do it this way at first because "username taken" will almost always happen only once, right when they join and first sync messages, so it makes sense to have a flow specific to that case. And it will happen very rarely until communities get large.

[Kacper-RF]

#1843

[kingalg]

We need to change hint font from 10 to 14 according to figma designs (Kacper is already fixing that).

[kingalg]

mobile@2.0.3-alpha.6 (iOS 333)
Done.