Multi-phase and multi-session pairing

[karalabe]

The current pairing mechanism is deliberately simplistic. One person creates an onion address and shares it with someone else. When that other person dials the address, they do a quick credential exchange and are done. This works ok for a PoC or even prototype.

---

Quoting from coronanet/rn-coronanet#1 (comment):

Spent a bit of time sketching out how the more advanced pairing could work. The use cases behind the below chart were:

• Support exchanging profiles before finalizing the pairing. This should help ensure that you are indeed "friending" the correct person. Note however, that the other side can easily lie and send arbitrary profiles, so this won't stop a proper attack, but it can avoid accidental pairings.
• Support pairing with more than one person through a single endpoint/secret. Here the point might be that you can use the QR code to add more friends at the same time, or alternatively send a single link to multiple people and have it work. This entails making the pairing long-er lived and accepting arbitrary many joins.
• You can create a pairing session, send the link over to your friend, and have them come back whenever. It doesn't have to be immediate. Note though, you must be online when they do decide to join you, since there's only direct, live communication in corona network.

Based on the above requirements, I sketched up the workflow below:

• Alice creates a pairing session. This is akin to creating a temporary identity and address which can be shared with random people and then just thrown away. The backend will return the identity and address.
• From this point onward Alice will do long-polls on the API, waiting for someone to come knocking on the pairing session (a blocking HTTP GET, which needs to be repeated until the session is torn down).
• Alice can send this temporary address to Bob via QR code scan, URL, or whatever best works. We just need to somehow get 64 bytes to Bob.
• Bob feeds this address into his Corona Network backend, which will connect to Alice through Tor and retrieve Alice's profile. Bob does not send his profile or any other data over yet. The point is that this is Alice's show (url), they need to prove themselves first.
• If Bob likes the profile, he clicks "Connect" on the UI, which will send their profile + pubkeys over to Alice via Tor. Bob's HTTP request is blocking until Alice reacts too.
• Alice's GET returns at this point with Bob's profile, if Alice likes it and hits Connect too, we can accept the pairing, sending over Alice's pubkey to Bob. At this point both sides have successfully paired and shared each other identities, so Corona Network can directly connect to each other and the pairing endpoint is not needed any more.
• Alice might keep it alive for other people or might tear it down.

Synchronicity requirements:

• Communication is always between 2 phones directly. Even if Alice shares the link on Facebook, both Alice and Bob must be online for the pairing exchange. This might need to be conveyed somehow via a UI (either tell Bob to try later, or automatically try in the background).
• Since Alice doesn't know when Bob will come knocking with his profile, she needs to poll the paring endpoint with a blocking HTTP GET. We could do it with websockets too, but I feel that would be a huge complication at this point, let's not go there just yet.
• After Bob accepts Alice's profile, we still need Alice to do the same. That might take long if Alice is not on her phone right now, so Bob needs to again do long polls, waiting for Alice to confirm the join.

This pairing workflow should be able to handle a lot of very complex interactions, but it is a lot more complex than the previous one.

---

I think I'll postpone this feature for a next phase for now, since it's not essential, rather a nice UI/UX nicety.