asynchronous user invites

currently, a pub invite encodes a private key that is used to connect to the pub that created it. if we generalize the concept of invite-as-keypair a little further, we could make invites without requiring administrative access to a pub. basically: follow publicly an invite keypair, and let the invitee use the invite keypair to follow their own feed.

more detailed flow:

• alice wants to invite bob to ssb
• alice generates a keypair K
• alice publishes a follow message following K.public
• alice encodes K, their public key, and a list of global addresses of peers that they have recently connected to, into an invite code <K.private, alice.public, pub_addrs[]>. alice sends this code to bob.
• bob receives and decodes the invite code.
• optionally, bob publishes a contact message following alice
• bob initializes K's feed and publishes a follow message in K, following bob, with a property noting that this is a usage of a temporary feed.
• bob connects with K.private to each of pub_addrs until a connection succeeds and the pub requests to replicate bob's feed.
• bob reconnects to the pub with their own keypair.
• later, alice replicates K's feed and bob's feed. alice may unfollow K and follow bob.

advantages:

• a user could generate their own invite codes, and could do so offline
• the follow graph could more closely map to the social layer
• core changes in scuttlebot are not required (except optionally - see below)

disadvantages:

• the invite codes are effectively single-use
• to create an invite, the user must (i think) be followed directly by a pub, because the invitee will have to be able to connect to the pub with the invite keypair (2 hops from the pub, if the pub follows the inviter), and then with their own key (3 hops from the pub). the ui could show the inviter if they cannot effectively generate an invite because they are not followed by a pub. pubs could increase their follow hops count to allow more people to use them for inviting, but i don't think there is a way currently that the inviter could detect this (except by using their own invite). possibly an sbot rpc method could be added to query the hop count, so that inviters could build a more accurate model of where they can invite peers.

Yes! I was thinking about something similar. I think there could be something in creating the invite messages on your own feed!

I like this.

I don't think we should underestimate the "the follow graph could more closely map to the social layer". This in itself has value I think. And it might make it a lot easier to fight spam if that should ever be a problem.

I agree we definitely need users to able to create an invite without a pub, but I can see some problems with this proposal.

One thing: now for every user, there is also the temp user. to invite someone, you generate a private key, and send it to them. What if they started using it like a normal identity?

What happens with invites that don't get accepted? it would mean you appear to be following a bunch of people who don't really exist. Hmm, I guess there is the proposal to skip requesting feeds which havn't changed, but info about those feeds would have to be lurking around somewhere.

One thing: now for every user, there is also the temp user. to invite someone, you generate a private key, and send it to them. What if they started using it like a normal identity?

Their application/UI could avoid giving them that option. if they went around that and used the feed as a normal identity anyway, they could do that.

One way to handle this: when the inviter follows the temp identity, they could include in the message some data indicating that the followed feed is a temp feed, and sign that with the temp identity. then application UIs could show on the temp feed's profile page that it is a temp identity created by the inviter, so people know what kind of identity they are dealing with.

Another option: if we had code to detect forked feeds and use that to mean "stop replicating this feed", the inviter could detect when the invite is used and then deliberately fork the temp feed.

What happens with invites that don't get accepted? it would mean you appear to be following a bunch of people who don't really exist. Hmm, I guess there is the proposal to skip requesting feeds which havn't changed, but info about those feeds would have to be lurking around somewhere.

Yes, they would take up resources in the replication. one way to address this: create a user-invites UI, that would list "outstanding invites", and give the user the option to cancel (unfollow) them - with encouragement to do so in order to free up resources. it could also list "accepted invites", which would each have the option to unfollow the temp feed and follow the invitee's own feed. other UIs listing feeds a user follows could be updated to hide the temp identities

Their application/UI could avoid giving them that option. if they went around that and used the feed as a normal identity anyway, they could do that.

That isn't good security design, it's much better to have a protocol that has well-defined behaviour, and not rely on the implementation being correct.

I have two ideas which might improve this model though:

There could be a way to terminate a feed - probably just set a property msg.terminal = true and after receiving a valid message with that, ssb does not replicate any more messages from them. Maybe a temp feed has to have a migrate message (directs to a new feed) which is also a terminal.

Another option, would be when following a temp feed, you'd follow it only for a specific number of messages - then if they start using it wrong, it would just unfollow them from the invitee

@ezdiy of course there's a lot to build.
I'm interested in simulating spam and malicious actors to help us improve the network resiliance.

If this is a problem that is of interest to you, we'd love to support you to make inroads on this area.