[EPIC] User should be able to join when owner is not online (discuss together and close)

[holmesworcester]

Update: let's talk this through as a team after the release, but I don't think there's any more to do here that isn't already captured in other issues

Background / problem:

Right now users can only join when the owner is online, which is a bad experience because it means they could be waiting an indeterminate amount of time to join, even if an online friend invites them.

We do it this way because to have impersonation-proof usernames we need to have some source of truth, and without a blockchain or a central server the simplest way to do it is to trust (and verify) a single user, i.e. the owner.

However, a better way to do it would be to create some provisional status for usernames, like guest accounts, or some kind of flag that marks a user as temporary, so that owners can confirm usernames when they come online.

Intermediate solution

We can:

1. remove connection authentication completely and let unregistered users "join" just by connecting to a peer and send messages with their reported name.
2. Display unregistered users as per these designs: https://www.figma.com/file/TV9pF84Ob8pLYRLu83gNol/Joining-when-owner-is-offline?type=design&node-id=7-2510&t=kfJWkGgw7kHlx4W5-0
3. Include multiple onion addresses in the invite link, e.g. the inviting user's address, the owner's address, the longest-online address and the most-often-online address. Then on joining we try all of them simultaneously. We already have logic for prioritizing onion addresses so we can include as much of this list as possible. **This will make it so users can join when the owner is offline.
4. Send the user registration request to the owner as a message with an attachment, and send the signed certificate back to the user as a message with an attachment. In our first implementation these can be public messages in the general channel. "User requested registration," e.g. and having this simplicity will help for debugging.

Note on peer discovery: this might already be taken care of but we should make sure that users still discover all peers in the community when they connect and start syncing, by syncing this data from OrbitDB. It's okay if their addresses are not added to this list until they are registered with owner.

[holmesworcester]

Other things:

1. Most important thing is that users understand what's happening, so we need something that invites them to click and see an explanation.
2. Users will see that their own name isn't verified, so they should get an explanation tailored to them in this case
3. Whatever the guest status is could be on everyone's name so it shouldn't make the channel unreadable
4. Checkmarks is the closest thing in normal apps to verification of names.

We may want to warn users in these cases:

1. When there are two or more "guest" users with the same name, we should show a warning next to their names.
2. When there are two or more official users with the same name, we should show a very aggressive full screen warning such as "Warning: impersonation attack. The community owner has given two people the same name. This should never happen, and it means the owner is malicious or compromised."

[holmesworcester]

Design here: https://www.figma.com/file/TV9pF84Ob8pLYRLu83gNol/Joining-when-owner-is-offline?type=design&node-id=7-2510&t=kfJWkGgw7kHlx4W5-0

I prefer the use of a soft label (rather than a warning) on new accounts and I prefer the word "Provisional" to "guest", "unofficial", and "unconfirmed", but we need to test these with users:

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

We also need to test the warning text with users to ensure that it is clear.

[holmesworcester]

Let's think about how to divide and swarm on this!!!

[vinkabuki]

could you explain:
Whatever the guest status is could be on everyone's name so it shouldn't make the channel unreadable

[EmiM]

How often this "Warning: impersonation attack" should appear? One time? Every time new user with duplicated name joins?

[holmesworcester]

could you explain:
Whatever the guest status is could be on everyone's name so it shouldn't make the channel unreadable

I mean that the 'guest' label (whatever it is) needs to be noticeable but unobtrusive.

[holmesworcester]

How often this "Warning: impersonation attack" should appear? One time? Every time new user with duplicated name joins?

Here's what I think makes sense:

If the owner hands out duplicate names (which should never happen) it should be very visible. On every restart, for example.

If people join with duplicate names and aren't registered yet, that should be a label on the name and it should just display wherever the name displays.

[holmesworcester]

I think we've sufficiently split this. Should I close this issue or keep it around as a reference?

[kingalg]

@holmesworcester can we settle a naming for different kind of users? It doesn't have to be something that will be there forever but right now we are using bunch of different names in issues and designs. We are just starting with this EPIC and we should be as much on the same page when we are taking about naming as possible to avoid confusion.

For example in #1559 we are using unregistered and provisional (so already 2 names) and then in designs we have "unofficial" which I guess is the same?

Now when we will be working on bunch of issues for this new feature we will probably remember what is what but give us few weeks or months and there will be questions "is this the same as that?". If you write naming preferred by you here I will take care of correcting it in places that I have an access to.

[holmesworcester]

Let's say 'unregistered' for now since that's the closest to what's happening.

[kingalg]

@holmesworcester
I’ve gathered team questions about registered and unregistered usernames. I’m going to start with what we know:

Those are designs: https://www.figma.com/file/TV9pF84Ob8pLYRLu83gNol/Joining-when-owner-is-offline?type=design&node-id=7-2510&mode=design&t=OmcWS5tshzJ4P3Hd-0

Those are names that can be found for two types of users:
Unregistered (also known as provisional on unofficial)
Registered (also known as official)

The unregistered user becomes registered once community owner accept the new user.

We have three potential situations/cases when usernames can be duplicated:

1. Two registered users with the same name.

This is suggested by design but nothing in our current process indicates that this is possible. I’ve consulted this with Kacper and there shouldn’t be a situation where the owner is able to give the same username to two different users.

(Question 1) Is this only “in case something goes really wrong with our project” or we are changing the process so the community owner can give the same username to different users as suggested by the warning modal?

I’m quite sure that I saw an issue for that but I can't find it. As we have this “EPIC” issue it would be good to have a list of all issues related to it.

2. Two unregistered users with the same username.

(Question 2) This can be quite common and as we don’t have an issue for that (or I can’t find it). I’m wondering how we are handling this.
Designs with figma suggest that we are treating this with very similar warning as in case 1. What bothers me in those designs is that we give the mobile user option “I understand” and desktop user has “Leave community”. (Question 3) Which one should it be?

3. There is a registered user and one or more unregistered users with the same name.

We have an issue for that (#1559) but I don’t see any designs. I don’t think that designs from case 2 because in those designs it states “More than one user is using the same provisional name”) which suggest that only unregistered users have the same usernames. (Question 4) What should be the design and client story for this case?

For each of this cases we need:

• Issue in github
• User story (to whom it will happen, when it happen what will be our reaction and possibilities for user)
• Design specific to particular case that is consistent for mobile and desktop.

(we can move this comment to the separate issue but I thought that having everything in one Epic would be easier)

[kingalg]

Would you like to have a short call with me so you can answer questions from my comment so I can prepare everything accordingly? (or you can write down your answers in comment if you prefer)

[holmesworcester]

I'll find the specific issues that correspond to these and post them here or create new issues.

[holmesworcester]

Here are the issues for the cases above.

1. Two registered users with the same name.

#119

2. Two unregistered users with the same username.
3. There is a registered user and one or more unregistered users with the same name.

#1559

If there are more questions about these, let's address them in their respective issues to keep things clear.

[EmiM]

@holmesworcester is there anything left to do in this epic? Can we close it?

[holmesworcester]

Sure we can close it! but let's talk it through on Thursday to make sure we're all on the same page and to see if there's any more work we want to name now and return to later.

I have some questions about invite links, like if we have any ideas for including more peers, and if we're clear on what happens in different scenarios. For example, maybe the inviter should always be a peer in their own invite link, just to give users a way to have some control or certainty that there is another peer online.

I'm also curious if anyone else can see gaps. Kinga might have helpful thoughts from her tearing for example.

[holmesworcester]

In thinking about this more I don't think it's necessary. Let's close the issue.