Alternatives to public pubs / open invites

Previously I wrote about benefits of pubs [%vOVOwGp...] and how they can improve in the future [%XOUlIjd...]. But that did not cover the use of pubs for new people onboarding to the network. If you don't have friends in the network, would peer-invites or p2p connections help? I want to explore a little the way people join the network via public pubs, and what are some alternatives.

Last I checked, the Patchwork readme and scuttlebutt.nz website recommend to join a pub from the pub servers registry github wiki page (recently re-organized: %smNtEg7...). These include "public pubs" which offer "open invites" - invite codes free to anyone who goes to the page. Some people have suggested this practice discontinue [%ongF09D..., %WGZUWw9..., %6HC2DZd..., %boFq/pP..., %/bJK5nK...], but it continues. "'Public pubs' are establishments that exist to foster new communities" [%FAFvsbb...]. People who don't operate pubs use public invites for onboarding friends [%zcApFNW...]. In that case, integration of ssb-peer-invites into clients, and further deployment of it on pubs, should fix the problem. But for the case of people hearing about the network via podcasts, blog posts, articles, etc., how do they connect?

Here are some notes and links related to alternative options for onboarding people without an existing personal connection:

• "learn from Mastodon about federated pubs (each pub has a clear purpose, code of conduct, maybe location)." [%jm+KbND...]
• "think about what (besides topic or location) attracts people to particular Mastodon servers or eMail servers." [%1bIiAx4...]
• invites codes for purchase [%OoVDyWk...] or by donation [%/ZFfnE1...]
• A pub could have a form for people to fill out to request an invite. They could be asked why they want to join, and/or external contact info. Then that info could be presented for approval to the pub operator(s), or a private group, or a public channel. Downside is asynchrony, so the new person would have to wait for an email or something to get their invite. Or the system could approve them automatically and/or provisionally.
• Pubs could unfollow new users after some time has passed [%6+gmXsy..., %6coPYLv...] or the user has gotten established in the social network [%sDaPT+E...].
• Let people volunteer to help onboard new people by escrowing peer-invites from their own id into a trusted pub/website/service. Then when people request an invite from that service, they get one from its store of user-invites. It would be like assigning an onboarding buddy or guide who has voluntered to help a new person in. This could give more a personal touch to onboarding, and also spread risk and avoid social graph flattening.
• Spacial-associated or organization-associated or interest-based pubs. "like 'people who love this local coffee shop' micro" [%f6ZRXO2...]. "bring geographically close people together […] or bring people interested in the same thing together" [%77J5LPn...]. local pubs via pirate boxes [%/ZBVKKH...]. Are there any hackerspaces that have an automated/systematic way for people to onboard to SSB via being at the space or being a member of it?
• SSB Pub As A Service (SSBPAAS) [%1TVZigD..., %f6ZRXO2...]

Special-purpose pubs:

• Mirrors [%OkwWfFx...]
• Antennas, Bees [%75TLIcL...]
• or not [%31Vpwhq...]

More metaphors for pubs:

• "signal boosters" or "speakers on a pole" [%5nezGz8...]
• "in amateur radio terms, like a repeater" [%b2KGAV5...]
• poste restante mailboxes [%+6F81zB...]
• non-drinking-related [%AvKuW2j...]
• "meeting places for self-organizing communities" [%FAFvsbb...]
• "your first friend" [%RL2oLBD...]

Good thread @cel. Not sure which of these 3 threads I should reply to, but I'm choosing this one.

I think ssb-tunnel will open a lot of interesting use cases. There are a couple of use cases for pubs that we could consider decoupling and offering separately.

• (A) Pub as a public-internet IP address connection to an SSB peer
• (B) Pub as an online mirror of data for some feeds
• (C) Pub as an onboarding mechanism to discover more feeds

ssb-tunnel over the existing pubs infrastructure is a low hanging fruit, and helps to achieve use case (A). I would also like to get started building ssb rooms which is essentially like a pub, but used only for ssb-tunnel, it never replicates content online. I like the idea that rooms could also serve for use case (C). You could join (and here the meaning of the word 'join' is accurate) a room and discover new people. Rooms could also be around a specific topic. What LAN sync does for discovering peers in a common location, rooms could do for discovering peers with a common interest around the globe. I believe a lot of rooms could be open-invite, because we could build it so that replication happens only if there is mutual interest and opt-in among the 2 peers. This would help against the rando effect: you would see a rando but you wouldn't get their data (e.g. their comments) unless you opt-in and they opt-in too.

Use case (B) is where pubs really shine, so far I can't see another better way of providing an always-online mirror of data that is powerful because it removes the requirement to be online simultaneously. Rooms would require peers to be simultaneously online if they want to replicate data.

I'll add an idea I have been thinking about to this mix. Its the idea of SSB friend pubs. Its a service you run for you and the people you are connected to. In this way it is closer to SSB-mirrors than open pubs.

Its a pub you run and befriend, to enable to hops to function properly. You can also use the pub to invite people you know, something that will be peer-invites will be ingrated into clients.

Because closely follows your hops, you can start using that to create services for the people in your social graph. This means we can start running ssb-dat-autoshare to automatically seed dat links without having to mirror the whole network. And you can start enable ssb-incoming-guard on the pub to make it harder for people to harvest the whole network and use that to do surveillance capitalism analysis.

That was the server part. On the client side (patchbay), I have been working on ssb-friend-pub that helps you connect to only your own pub or pubs run by your friends. Secondly enable posting dat links for larger files.

I'm running my pub in this mode, but I'm thinking it would make great sense to either be able to configure #peach-cloud to do this, or to have a special distribution so that you can run it easily on raspberry pies.