[marknadal]

Apologies, @staltz could you expand more? Is this centralized? Or federated, along the lines of Mastodon?

Why not do this decentralized? Should be possible. NAB (p2p Reddit) does something similar with GUN via "spaces" that are under a public key, but requires no centralized host/server/etc. should be trivial to do the same in SSB.

[staltz]

Rooms are decentralized. It's not following the end-to-end principle, because rooms are intermediaries, but there can be many rooms, they are fungible, and they are not hard coded anywhere. It's possible to build similar functionality on a DHT, but it has a couple of downsides:

1. The bootstrapping servers for DHTs are legitimately centralized and hard-coded servers 2. On a DHT you leak your IP address to many other peers, with rooms you leak your IP address only to the room administrator. (This is supposing without an anonymization layer, which would have some non-negligible overhead) 3. Connecting to DHT peers is not as reliable and consistently functioning as a static IP address, considering all sorts of network situations, specially mobile data plans

That said, I don't have anything against DHTs, and in fact I might improve how Manyverse uses DHTs. I just think it's important that users know the drawbacks of each approach, and then users can choose whichever approach fits their needs best. This is why Manyverse focuses on multiple connectivity modes: LAN, Bluetooth, Pubs, Rooms, DHTs. I think the more of these we have, the more resilient the network will be. So my argument isn't for rooms instead of DHTs, my argument is that adding rooms is good to fill in a gap in choices for connectivity.

[olah_1]

Seems like it's federated and if you really connect with someone you meet, you can probably choose to become "friends" and store each others' directly, bypassing that federated/centralized server.

[black_puppydog]

SSB as a technology is about as decentralized as it gets. All posts are stored locally, you can write posts and replies and do everything offline. Then when you share some medium with other peers, they gossip all their updates, as well of the updates of their friends and friends of friends.

That medium can be a shared wifi (if it allows UPD multicast) or it can be bluetooth (only for manyverse so far... desktop bluetooth gossip is haaaard) but at the moment, the shared "medium" is often an internet server. These servers ("pubs") are not any different from normal ssb peers, they just expose a public IP and don't have NAT.

There's two issues that people take with pubs:

1. They make the ecosystem less decentralized, moving it more towards a sort of federation. But it's not like you only connect to the pubs you select. Usually an ssb application will connect to many different pubs that it knows about, so there's no single point of failure there. 2. Following a pub means that you get blasted with a fire hose full of random strangers' (everyone who signed up for that pub, plus their friends) posts, which take up space on your drive, and (more importantly) need to be verified and indexed locally. That makes onboarding very slow and tedious, especially on mobile devices.

Rooms relate to the latter. They're an easy way to have a pub server that only connects you to the group of people you want to be connected to. Well, if you don't share invites to it around freely that is. And it's simple to set up, even for less technical people. Maybe think of it like a NAT traversal with extra crypto. Like that, onboarding a friend onto SSB is a bit more elegant: you still give them an invite, but to a room for a social circle that they already fit into, or even a room just for you and them. Now instead of having to let the device sit and digest a thousand feeds over night, it only gets the feeds they would want to know about. It's much more like local off-grid onboarding.