Hacker News Reader

Comment by davidgerard | Hacker News Reader

and that the linked post is a lengthy apologia for the network having an incredibly obvious unremovable central point of control even as they pretend it doesn't.

Centralisation is a feature in social networks: being able to find your friends is the very first thing. But don't then pretend you aren't.

Every now and then I post to Bluesky asking: so what's the loadout for Bluesky? How many servers does it take to run this thing? What would it take to run my own?

These questions never quite seem to get answered or documented that I could find.

A "PDS" is a reasonable Ubuntu box. They seem unable to admit what it takes to run the rest, though.

View on HN

Sorry, can you explain what unremovable central point of control you're referring to?

Looking at the federation architecture[0] shows that the network is inherently reliant on using a relay (or BGS - basically it's a giant data gathering server that generates the "external timeline" for applications using ATproto) - it's not possible for two PDSes to directly connect with one another (since a PDS does not store data from external users, but a relay does), which means that if a large relay falls apart, the entire part of that network goes down with it.

Similarly, if a relay decides to nullroute you, you are functionally up on shitcreek, which because it's all handled by the relay is way worse than getting a Mastodon instance filtered.

If we use a torrent analogy, it's not possible to use Bluesky/ATproto with DHT/peer discovery, you're required to connect to a tracker who then decides who you can peer with.

(Relatedly, AcitivityPub also supports the use of relays for discovery, but doesn't require them. It's just not often used because they tend to be a moderation firehose.)

[0]: https://blueskyweb.xyz/blog/5-5-2023-federation-architecture

FYI the person you're replying to is the author of the post and a Bluesky dev

I just noticed that, thanks! Adjusted the tone a slight amount to be a bit more direct.

Relays aren't hard-coded and PDSes are encouraged to connect to as many relays as they want. They are essentially network busses that help reduce the combinatorial explosion of connections between nodes. It is entirely possible for PDSes to connect directly to each other if they're so inclined.

It's still a notable bit of centralization present in the protocol - from the documentation presented, it's obvious that moreso than any other "node" in the software, if the relay breaks, that entire chunk of the network stops working. A PDS, a labeler or a feed generator vanishing means very little for the network on the whole, while the relay vanishing causes everything to fall apart.

Similarly, the fact Bluesky is offering a PDS implementation for self-hosting[0] but not a relay[1] tells me that hosting a relay is more than a non-trivial matter, although I'd love to be proven wrong there.

[0]: https://github.com/bluesky-social/pds

[1]: Well, outside of literally deploying Blueskys own implementation - https://github.com/bluesky-social/indigo/tree/main/cmd/bigsk... .

Reply on news.ycombinator.com