-
Notifications
You must be signed in to change notification settings - Fork 88
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
Put multiple libp2p addresses in invite link #1557
Comments
It's confusing, afaik we want to connect to community peers immediately and put a csr in orbitdb, right? |
This is also quite a lot of work as we have to change the joining/registration flow and all related events exchange. |
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. |
Checked URL size that will linkify for some of the apps. The number is the number of params' characters (after Whatsapp: 640 too many, 512 OK (on mobile). Desktop seems to not have restrictions - tested up to 2055 Whatsapp and Signal are the most restrictive. |
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? |
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. |
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. |
@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? |
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? |
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. |
Old invite links not working is fine. |
so each pair takes 104 characters. |
Which addresses do we currently choose? Can you describe the criteria? |
@EmiM should this be in "waiting for review"? |
Known issues (to be resolved in next iteration):
|
What's the "same url" case? |
And is there a way we can add the community invite link to existing communities? Or is that done? |
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).
Invitation url is constructed from connected/most active peers so... it is done. |
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? |
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 |
Version: 2.0.1-alpha.7 |
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.
The text was updated successfully, but these errors were encountered: