@Pospi %LbpUX7N...

I don't think pubs are evil or should go away necessarily. However, their role/usage can change.

I would like to identify some good properties of the current SSB pub system. The main thing is the way they enable decentralization.

Decentralized server discovery

Without pubs, how will you connect to peers over the Internet? If you use a DHT, or overlay network, you still have to make initial connections to some servers. If those server addresses are hard-coded, you have centralization. With pubs, you discover their addresses in the feeds that you replicate. As a pub operator you can publish your pub address on SSB and peers will connect to it. Additionally, with pub invites, users automatically publish addresses of pubs they connect to, which further propogates pub addresses, enabling peers to discover a pub address when replicating the feed of a user who used an invite code to that pub, not actually having to replicate the pub's feed.

This decentralization aspect can be applied to other uses. For example, say you don't want to use pubs, and want peers to connect using WebRTC instead. The usual way is to have peers connect to a signalling server and maybe STUN or TURN servers. What server addresses will you use? Let peers discover them in their SSB log. Then people operating signalling servers or STUN/TURN servers can publish addresses for them, and peers can discover them, and maybe their app can give them an option of which to use.

Secondary positive aspects of pubs

Servers have identities in the network. They are not just in the background and unnoticible (until you can't connect to them), they have a feed just like users do. They have a presence in the social space. They can be mentioned, described, followed or blocked. You can see their position in the social graph and their history of activity. I consider this to be part of what is sometimes called how SSB is "honest" [%VTbtugC...]: servers exist and have identities, and we make that visible.

Pubs are peers (not to be confused with %kfd7QID...). At the connection level, while pubs function as intermediaries between peers, they are using the same protocol as the peers (aside from that non-pubs initiate connections to pubs, not the other way around). Because of SSB's P2P/E2E design, a pub's position in the network graph does not imply much or any authority over peers. I think this is why we've been able to get away for so long with not having direct p2p connections between peers: the gossip protocols work.

Summary

I think pubs are a good idea because they give identity to servers. However, if you want to do without pubs (as an implementer), I would still recommend following their example in the way of address discovery via SSB messages, if you want a decentralized/p2p network. For launching new protocols/networks, I would in fact still recommend to use pubs: publish their server addresses and capabilities in their feeds, so to accomplish decentralized server/service discovery and integrate with the social-network identity of the pub.

related: %t7iX0hA...

Related somebody-should: Add a multiserver address type that is a pair (NATed-ip4, STUN-server) that can be gossiped around. That does not help with initially joining the overlay, but once you are in, natted peers can participate in the regular gossip-based overlay construction/diffusion. This approach is more dynamic than tying an identity to the servers it published in its log.

Thanks @cel! You know, it's entirely possible I confused you with someone else and you never said that at all.

The "evil" part from my perspective comes down to protecting the network from trolls and spammers. You're right- the problem is less with pubs and more with how they are used- having big locuses of activity which serve as gateways to the network makes it all to easy to disrupt everyone- a problem which would largely go away if communities were more self-contained.

I do think we need to make it super easy to set up a pub for oneself (perhaps it already is, that's still on my to-do list), because having a "shadow" of yourself that is always online to replicate your data to friends and help them join you on the network would be a very good thing.

There's probably also an avenue to not need them for the simple case of in-person, synchronous onboarding:

• Upgrade SSB with uPnP support so it can punch through NAT gateways easily
• Use some (probably centralised, sadly) service to detect one's public external IP
  • (Actually, maybe you could do this by having your peers gossip the IP address they see you on back to you)
• Make it super easy to generate an invite link in the UI, where the invite link includes all the necessary addressing / routing information to connect to one's running sbot

With these requirements satisfied I imagine it would be pretty easy to onboard others even where no shared local area network is available?