Invite over Internet

[RangerMauve]

Description

We need a way to add members to a project when they aren't on the same wifi network but have a means to send each other messages through whatsapp or email.

Some tradeoffs to consider:

• must work even if both users are not online at the same time
• must prevent evesdroppers from reading secrets
• should allow the invited peer to exchange with an archive server after the invite process.

Proposed flow:

• Invitee wants to join a project
• They generate a keypair used for sealed box encryption
• They make an "invite request link" with the public key, their device ID, and a name
• They send the link to the invitor
• The invitor clicks the link which opens the comapeo app to ask if they want to add this person and to choose a role to offer them.
• On confirmation, the invitor makes an "invite response link" which contains project keys, archive server info, name, and description; all encrypted for the invitee's public key
• The invitor adds the device id with the chosen role and exchanges with the archive server
• The invitor sends the link to the invitee
• The invitee clicks the link and opens the app to a page confirming the project join
• They use the keys to init the project and perform an initial sync

Tasks

TODO pending initial review

• [ ]

[gmaclennan]

This looks good to me. Some additional considerations:

1. If the user opens the link on a device without CoMapeo installed (or on a non-mobile device) then we should show a QR code that encodes the link, and a link to download/install CoMapeo. User story: A user has two phones: a personal phone with WhatsApp installed, and a phone given by the community for CoMapeo mapping. They receive the message on their personal phone, but need the invite on their CoMapeo phone, so they scan the QR code from one phone to the other, and it opens the link on the CoMapeo phone.,
2. Because of the QR code requirement, we need to keep the URL to 300-400 bytes, because the QR code could be displayed on a screen that is cracked or dirty (common with many field phones) and the camera scanning the QR code will be from a low-end phone, so the QR code needs a high-ish redundancy and should not be too detailed. I'm not sure what the exact boundaries should be for us, so maybe worth a quick bit of research to get some guidelines on what our max size should be.
3. As discussed: URL payload in the #, so it doesn't get sent to the server.
4. Will need a simple server (static web page) to render the QR code (client-side), probably at https://m.comapeo.app. Cloudflare Pages is probably best for this for us.
5. The private key created by the invitee needs to be persisted, because the app could be shut down and restarted before receiving the invite response. Persisting sensitive keys on mobile is tough from Node, because of lack of access to native APIs. One solution is to have a simple counter, which we persist to our main client SQLite DB, then generate a keypair with that counter as a hash, and include the counter/id in the invite round-trip, so the invitee can re-generate the keypair from their root key + invite request ID.
6. Need to verify how the app behaves when in the "has project keys but no initial sync (therefore no custom categories or info about devices in the project)" state. This may require design and front-end work - we might want to restrict creating observations until initial sync is complete.
7. Is it worth signing the invitee invite request, to prove it comes from the owner of the device ID in the request?

[RangerMauve]

TODO: Have invitor add device ID/name/type

[RangerMauve]

Depends on #1053