 People describe ATProto as federated, and that has always bugged me. And I think I figured out why. It's not NOT federated. But that's deceptively incomplete. It's much more complete to say that ATProto is brokered. I get why they do it. ATP describes itself as federated, after all. But there's a broker, and everything is mediated by the broker, which they name a "relay" (and used to call a big graph server, which was actually more honest). 4 comments
And that ultimately is also why I don't view bsky with much optimism. When they run out of venture cash, they will either go belly up or give up control of the broker to become a surveillance capital device. And I think we know which one they'll choose. Either way, the fate of the network is tied directly to the fate of the company. For all their talk about openness and federation and whatever, this fact is by design. It's their network, and neither can survive without the other. Which means it's ultimately not so different from cohost. Except I always put a lot more faith in the principles of the cohost devs.  @jenniferplusplus I don't trust AT protocol, thus I don't trust Bluesky. I think the folks running the org are good people, but I consider it a mistake to label it as part of the "fediverse". To me, fediverse = ActivityPub. Always has been, always will be. If it's not a W3C spec, it's not a component of the open web. That's why I've shut down my account there and don't plan to return. |
Gregory's Server
You can't realistically run your own broker. It's enormously expensive, and also no one would trust it, or even know it exists. You have to connect to the bsky broker. Which means bluesky controls the network, and you have to have their permission to join it.
This breaks one of the core, but often unstated assumptions people have about federated networks: that they are permission-less.