March ssbc-grants Proposal: user invites.

I have spent the past two months working on improving epidemic broadcast trees good enough to roll them out fully. That is just about ready, and I decided it was best to focus on another onboarding-themed proposal: user invites. We've discussed this idea before but unfortunately it still hasn't happened. However, since we now have ssb-ooo we have some new options to play with.

User Invites

Currently, to join the ssb network, you need to "join a pub", or be onboarded by someone in the same wifi network. Personally, I have never liked the phrase "join a pub". It makes ssb feel federated instead of p2p-decentralized. People are frequently confused about what pubs are. But we have needed them to be able get people into the network.

This proposal won't remove the need for pubs, but it hopefully will remove the need for pub invite codes. Instead an invite will come directly from another human, a member of the network, not just copied from a web page. This means when they arrive they are not a stranger, but were invited in by someone. So, in a way this is also a moderation feature.

rough sketch

A regular user, Alice creates an invite code for "Bob" (via user interface in their client) then sends that to their friend Bob via some other messaging system that they already mostly trust, such as email.

Invite codes will have names preassociated with them, so when bob arrives, everyone know's it's Alice's "Bob". It doesn't have to be their real name, and Bob will also see the name before confirming. (Alice will be warned to consider Bob's level of desired privacy before naming them)

From there the new user pastes it into their app in the same way an ordinary invite works. This will allow Bob to connect to a pub and say "It's okay I'm with Alice". This will cause the pub to follow Bob, but Bob will only follow Alice, and not the pub. (but may replicate the pub via alice's 2nd hop)

When Alice next replicates the pub, she'll get a notification in her app that Bob accepted her invite, (with invitation to follow back). If Alice follows Bob, he is now fully in the network.

this proposal includes

• figuring out all the details how this will work (I intend to take this part very seriously, there are security/privacy considerations)
• implementing server stuff & tests
• writing library to make pull requests into client apps easy
• making at least one PR to a client app (probably patchwork)

ETA

I'm hoping this can be achived in march, but depending on how much life interferes may be march-april.

Big yes to this proposal, I'm cautious of publicly launching mmmmm before user invites are ready, because of user experience.

@moid auditable: yes. That will be the goal. Alice will create an invite on her log, which will be referenced by the pub. Probably the invite will include a name and possibly an introduction.
(when introducing people, try to complement them both!). When you accept an invite, that will be linked back to the specific invite you accepted.

Some people desire anonymonity, and that is okay, pub invites will probably not go away completely.

Cool proposal.

I had an idea when we were in Mexico, I don't know if it useful, but seems relevant here.

One of the org patterns that I think works very well in many contexts, is concentric membership circles. Roughly, the concept is:

• The org/network/group is formed with Mollys at the core, and Larrys at the perimeter.
• Any Molly can invite any new Larry: to become a Larry you only need the trust of one Molly.
• To become a Molly, you need the trust of all the other Mollys. (Or a supermajority of Mollys.)
• i.e. it is pretty easy to join and start participating, but you can only get into the core once a lot of people know your work and trust your character.
• Mollys have more rights and responsibilities than Larrys (e.g. backstop governance powers), but mostly they are just there to filter out the population so your group is composed of values-coherent people.
• Graduating from Larryhood to Mollyhood is a nice psychological barrier which combines "my contributions have been acknowledged!" with "I'm responsible for looking after this place now."

So I like the pattern, I've seen it help in many different organising contexts, and I was idly wondering if it could be useful to implement this systematically with something like invite codes.

Haha @alanz I just chose those names because they are neutral.

At Enspiral we call Mollys "members" and Larrys "contributors", which is okay, but not ideal because most contributors would think of themselves as "members of the community", in the natural sense of the word.

When our swarm/team at Loomio adopted this org pattern we just had an open conversation with everyone who was participating. Eventually we found 6 people who were able to commit and prioritise the project, so they became the inner core (we call them Members too, because they have a legal membership in the cooperative company). Everyone else was a "contributor". Over time, some of the contributors moved on, and some of them stepped in to the core.

I feel I may be derailing this thread though

hey @dominic I think the invite system would love this attention.

Can you clarify - ebt is not involved at all here, but ooo is, correct?

My thoughts about implementing this were to use @mikey's awesome bot framework - I'm super keen to see pubs as things you can send a message to and have them execute commands - in this context "pub my friend Emiliy is inbound, can you make me an invite for her, and also handle all that stuff when she arrives, like introducing us, and following her".
All that communication could be done as PMs with the pub, and the butt-chain then becomes the log of actions the bot has taken, and needs to take.... if the bot uses the private thread with you can also observe the progress.

Fun bonus idea - don't use a string code, which is ugly and confusing and easy to copy wrong, use an image with the code stenographically embedded in it:

(this image does not have anything embedded in it.. to my knowledge)

cc @Dan Hassan - the stenography master

bonus bonus : make the image an empty hermit crab shell illustrated by @angelica

another ideas:

• many pub invites embedded
• asynchronous invite use
  • publish a PM to the pub announcing yourself, so if the pub was offline or you were when you next connect you are all good
  • nice way to start a private conversation with the pub and for it to introduce itself

@moid yes, exactly. This is a classic move in the web 2.0 playbook. It's believed that a perception of exclusivity can make inclusion seem more desireable.

@alanna this doesn't mean a pub owner can't give out invites publically. hmm, I may have been unclear, here:

This proposal won't remove the need for pubs, but it hopefully will remove the need for pub invite codes.

emphasis on need, if a pub owner wanted to give out public invites that ability won't be removed (for example, because they wanted to be in a more roudy network)

But we'll have another way to do invites that are more directly related to a specific peron. It's more about broadening the moves we have available.

@mixmix I'll look at that, but this probably wouldn't be a straightforward bot, because cryptographic generation of the invite code should be done on the client. (so we are fully removing the power, except as a verifier, of the pub)

Sounds great. Exciting times :D.

@customdesigned that's a good point, but the main reason we'll still need pubs is because direct p2p (via cjdns or othewise) would require your peer to be online to process the invite - maybe this is reasonable with a desktop user but personally I close my laptop frequently.

Also, this proposal includes some aspects that would be useful even with direct p2p - such as setting the name of the invitee.