specify invite consumption in details

[staltz]

@cryptix, would appreciate your feedback. A summary of the new invite spec:

The user journey flows in this order:

1. Invite code
   • Note that the length and encoding is not in the spec, this is anything the room implementation wants it to be
2. Invite Web URL
   • Shared via a third-party channel (e.g. WhatsApp)
   • E.g. https://${roomHost}/join?invite=${inviteCode}
3. Invite façade
   • This is the HTML response for the URL above
4. Invite SSB URI
   • This is necessarily rendered inside the façade above
   • ssb:experimental?action=join-room&invite=${inviteCode}&postTo=${submissionUrl}
   • Note that submissionUrl is not in the spec, this is anything the room implementation wants it to be
5. ID submission
   • The SSB app parses the URI and makes a POST request to submissionUrl with the JSON body:
     • {"id":"${id}","invite":"${inviteCode}"}
   • The server receives the request, and if everything is right, makes the invitee become an internal user, and responds with the JSON body
     • {"multiserverAddress":"${roomMsAddr}"}
   • The client gets the response, and with roomMsAddr it can now make muxrpc connections to the room and has internal user rights

[staltz]

Oh, I had another idea, which would make this feature more consistent with Aliases.

Aliases have two ways you can consume them. Given, alice.room.com, you can:

• HTML GET: Open the browser at alice.room.com, get an SSB URI that has more details
• JSON GET: Input alice.room.com directly in your SSB app, which will then fetch details at https://alice.room.com/?encoding=json

We could do similarly for invites, it's just an addition of the JSON GET:

• HTML GET: (specced in this PR) Open the browser at https://room.com/join?invite=123xyz, get an SSB URI that has more details
• JSON GET: (would be added to this PR) Input https://room.com/join?invite=123xyz directly in your SSB app, which will then fetch details at https://room.com/join?invite=123xyz&encoding=json

How does this sound @cryptix ?

[cryptix]

Yup, nice. The latter sounds like what I had in mind, too.

I'm not sure if we should use Accept Header or ?encoding= for the JSON requests in the app but that is a minor detail and the flow is much more concrete like this, I believe.