Clearify intended causality to follow after invite consumption

[cryptix]

In general the document is saying "mutual follows are required to build a tunnel" but the document is scarce on how this will work for new guests/people consuming invites.

While the consuming side can follow the creators public key since it's on the tunnel address, it's currently not specified how this will happen for the creator.

So in general we need some mechanism so that the the consumer can tell the room their public key and then the room needs to notify the creator that the invite was consumed (and that new public key they need to follow/allow).

Two solutions come to mind with varying tradeoffs:

1) Have the creator check the room for consumed invites. Either via polling some HTTP endpoint or via some muxrpc source to be a bit more event driven. This might be a bit quirky or delay intensive. The client would need to remember some state for resumption. Sounds a lot like a log/feed.

2) Have the room send a SSB direct message to the creator. Easy resumption and even transport the notification across different routes, not just between room to creator. Downside: the room would publish stuff just for this one case(?) and not as ephemeral (with the current ssb feed format at least).

[cryptix]

Solution idea three: Introduce the concept of ssb-invite over tunnels.

This would require a supporting client to register an invite token which then also adds the guest keypair of the seed to their local app for incoming connections.

In this case the consuming side will use the guest keypair (which also needs to be allowed by the room) for the first connection to the creator. In this it will call invite.accept with it's long term key which will yield a follow/allow on the creator for future connections.

I'm hesitant to just re-use the ssb-invite code because it might lead to misleading type:pub messages being published but the concept would be the same.

Clear benefit over 1 and 2: No polling or connected streaming required. No extra messages being published on feeds.

The downside here is that only supporting client software could register invites. Or they would have to click it on the web and create the invite in a pending stage until the app creates the seed and communicates it to the room (essentially bringing us back to a similar chicken and egg but at a per-requisite stage of the invite dance).

[arj03]

Some of this sounds like an awful lot like peer invites. The key being, is this an open invite or a personal invite. If it's an open invite, then would you automatically follow anyone that consumed the invite (assuming you would have a way of knowing?).

I'll try to zoom out a bit here. So we have room invites which basically gives someone the ability to see other peers in the room and to try an initiate connections. In the case of a new person coming in, I'm not sure if it's the best idea to create a tight coupling between invite and follow. I would imagine that a client would use the alias system to show better names for the available people in a room. In that case, lets say I create an invite an send it to you over some other channel, then you register an alias and I would know that well it's probably cryptix that just popped into the possible connections because I just send you the invite and I can follow you before connecting.

[staltz]

but the document is scarce on how this will work for new guests/people consuming invites.

This UX report might supplement that a bit: https://gitlab.com/staltz/manyverse/-/wikis/UX-project:-%22Welcome-to-the-Manyverse%22 (See Sprint 3)

So in general we need some mechanism so that the the consumer can tell the room their public key and then the room needs to notify the creator that the invite was consumed (and that new public key they need to follow/allow).

This was the "Inbox" idea I had mentioned sometimes, I dropped it because it's one more database and we'd need a delete policy for old invites that were never consumed.

---

There's two different things which are worth acknowledging: (1) invitation to become a room member (let's call it a membership invite) and (2) consuming an alias (let's call it alias consumption, as the document already uses).

If Alice creates a membership invite for Bob, this has nothing to do with Bob following Alice, it simply grants Bob access to the room (in case it's Community or Restricted mode). We could (and probably might make sense as a UX optimization) add some extra data on the invite code, showing that it was Alice who originally invited Bob, to facilitate Bob automatically following Alice once he joins the room, but that is not the central concern of the membership invitation. If we don't implement that, it's not a problem, because it's not the purpose of membership invitation.

However, if Alice gives Bob her alias, and Bob proceeds to do alias consumption, then the protocol specifies how Bob will automatically follow Alice (as you said, this is easy as it's in the tunnel address). Note, Bob does not need to be a member of the room, i.e. it is not a prerequisite that Bob has previously received a membership invitation. Bob can be the so-called external user. (Internal user is synonym with member)

How Alice follows Bob is specified in tunneled authentication, which assumes that both Alice and Bob are currently online in the room. If Bob is connected to the room, trying to do alias consumption, but Alice is offline, then to Bob it will seem like the connection failed, but it should be retried again automatically later (ssb-conn would handle this). This is why we don't need the Inbox idea. When (finally) both Alice and Bob are online in the room at the same time, then Bob will retry alias consumption, and Alice (through ssb-room-client code) would detect a connection attempt, and this would be displayed on the UI, and Alice can then make a conscious choice to allow or disallow.

[cryptix]

@staltz I get the first part about membership invite. That's not what this issue is about.

This is about tunneled authentication as you call it. Your solution is that both have to be online at the same time. That's a fourth solution to mine above and comes with a at least one other drawback beyond synchronized uptime of both parties, mainly that the creating side might not know yet who that public key is. Like, there could be multiple open invites and it could even be a invited created by another member of the room.

[staltz]

Yeah, I understand those downsides, but could you clarify what you meant with "Like, there could be multiple open invites and it could even be a invited created by another member of the room.", I don't understand that part (if we're talking about tunneled auth, there are no invites).

[cryptix]

there could be multiple open invites

Let's say we both use the same room and we both create 3 invites for some friends. They all become members immediately but how do I know which of of the 6 requests I'm getting are my 3 friends and which ones are yours?

[staltz]

Ah, right, you're describing a problem that currently exists also with room1. Let's call that problem stranger identification (you see, I like naming things). The solution we've been using informally with room1 is to inform the SSB ID in a third-party channel (the same communications medium you used for sharing the invite code in the first place). Or then, a time-based method to solve stranger identification, such as what arj mentioned above.

One thing I used to have in room1 was a name field for each peer on the room server, but Dominic encouraged me to get rid of that since it could be forged/lied by the server. I think we could use aliases to solve stranger identification, because aliases are signed by the alias owners, this could help give an idea who is who in the room. Yes, it requires new members to register an alias soon, but that doesn't sound too unreasonable to me.

[cryptix]

Hmmm okay, that could work. So to solve the stranger identification by the consumer registering an alias. I'd wager that this is the inbox hiding there.

In my mental frame it would be preferable to tie the alias creation to the invite token so that we solve the problem above of which of these X new people is my friend? since the creator might not know what alias the consumer picked.

[staltz]

In my mental frame it would be preferable to tie the alias creation to the invite token so that we solve the problem above of which of these X new people is my friend? since the creator might not know what alias the consumer picked.

Hmm, this sounds like a good idea, let me see if I understood correctly:

In the membership invite, the creator of the invite can attach a recommended alias field (this would be a query param on the SSB URI for the invite), and then once the invite consumer uses that invite code, they connect to the room, but they also automatically then perform alias registration with the recommended alias? In the app, I would probably add a prompt so the user can confirm that that's what they want to be called (otherwise they would have to revoke the alias and do it again), but still, this is a decent idea.

I think technically it just boils down to allowing the invite URI have extra query params that apps can then use however they want (I can also see apps that would ignore the recommended alias field and thus not register an alias). Note, all of this is functionality built on the client-side, no room server changes are needed.

[cryptix]

Yea, I can see how this can work.

I think we can close this, then.