Put multiple libp2p addresses in invite link

[holmesworcester]

As part of #1340 we should give invite codes as many onion addresses is practical, since the more URLs the greater the chances of connecting. We should put the owner and inviter first and then sort using the prioritization we currently have e.g. last-seen.

For a limit, quickly figure out what the max URL size is that Whatsapp, Signal, and Gmail will linkify and pick a number that fits. IE had a 2048 character limit and would return an error, but it's been deprecated.

We should behave gracefully if an onion address is truncated by some other app, just in case. A truncated final onion address should not cause an error.

[vinkabuki]

It's confusing, afaik we want to connect to community peers immediately and put a csr in orbitdb, right?

[vinkabuki]

This is also quite a lot of work as we have to change the joining/registration flow and all related events exchange.

[holmesworcester]

It's confusing, afaik we want to connect to community peers immediately and put a csr in orbitdb, right?

Yes we want to try to connect to as many peers as we can, so that we succeed even if only one of them is online and reachable.

This will also reduce the chances of having to retry to connect to someone, or of their onion address not being ready yet, because we will be connecting to multiple onion addresses.

[EmiM]

Checked URL size that will linkify for some of the apps. The number is the number of params' characters (after https://tryquiet.org/?codes=)

Whatsapp: 640 too many, 512 OK (on mobile). Desktop seems to not have restrictions - tested up to 2055
Signal: 640 too many, 512 OK
Google hangout: OK, tested up to 2055
Gmail: OK, tested up to 2055

Whatsapp and Signal are the most restrictive.

[holmesworcester]

Great research!

How does it fail? Does the URL fail to open or linkify? Or does it truncate the URL when you open it?

If we are designing this URL to still be valid when truncated (i.e. ignore a truncated onion address) can we just include a longer link because sometimes that works? Or do we have to limit our links to 512 for them to work in Whatsapp/Signal?

[EmiM]

Whatsapp and Signal just unlinkify params on receiver side if URL is too long:

[holmesworcester]

Is it related to the syntax? Would some other syntax for params without the ?= cause them to truncate the url at the length limit instead of unlinkifying all params?

I'm asking because the more information we can include here the better it will work.

[EmiM]

Tried with fragment identifier (https://tryquiet.org/join/#aaaaaaaaa(...)) and without parameters (https://tryquiet.org/join/aaaaaaaaa(...)) and those were also not transformed into link on the receiving side.

[EmiM]

@holmesworcester what about old invitation code (backward compatibility)? Since we are turning off registrar and will need a pair (peerid and address) to connect to the network, old invitation code will not work. Are you aware of that and are you OK with that?

[holmesworcester]

Yeah, breaking backward compatibility should be fine. The invite screen will just give people the new invite link, right?

We should make sure that the invite link updates properly in existing communities.

How many peers can we include in the invite link, with the peerid and onion address?

[EmiM]

Yes, new app will generate a new link but if someone would have old link from one of previous versions of Quiet, it will not work.

[holmesworcester]

Old invite links not working is fine.

[EmiM]

onionAddress -> 56 characters
peerId -> 46
"=" -> 1
"&" -> 1

so each pair takes 104 characters.
If we consider whatsapp and signal restrictions then we can only fit 4 or 5 addresses in URL

[EmiM]

#1686

[holmesworcester]

Which addresses do we currently choose? Can you describe the criteria?

[holmesworcester]

@EmiM should this be in "waiting for review"?

[EmiM]

Known issues (to be resolved in next iteration):

• invalid invitation code warning modal will not show right now (invalid code in deep link case)
• existing community will not have community metadata in db - Put community metadata to db when launching registrar - temporary bac… #1806
• UI for invitation URL is not pretty (url can be very long) - Fix invitation url UI for long urls #1778
• "The same url has been used to open an app (mobile)" case is temporarily (or forever) not handled because url can change often.

[holmesworcester]

What's the "same url" case?

[holmesworcester]

And is there a way we can add the community invite link to existing communities? Or is that done?

[EmiM]

What's the "same url" case?

I think it was handled to redirect user to the proper screen if they already registered to the same community (because they have the same registration url in redux that they are trying to use).

And is there a way we can add the community invite link to existing communities? Or is that done?

Invitation url is constructed from connected/most active peers so... it is done.

[holmesworcester]

Let's create a separate issue for 'opening invite link should take you to a community you have already joined'.

If any of the onion addresses in the invite link are known to us, we know that we have already joined this community.

Does that make sense or is there something I'm missing? Shall I create the issue?

[EmiM]

We support being a member of only one community at the time. There is no need to check if we belong to THIS community. If we belong to any community user gets info that he already belongs somewhere so the invitation link cannot be used anyway.

Adjust invitation code format to multiple addresses on website: #1803

[kingalg]

Version: 2.0.1-alpha.7
Done.