Bluesky, decentralisation, and the distribution of power Bluesky has seen a large inflow of new users following the results of the US election, and a significant amount of media attention as well. All that attention to Bluesky has also led to a renewed conversation around the question of whether Bluesky is decentralised or not. The terms decentralisation and federation are used in multiple ways: to describe the technological architecture details of an internet protocol, but just as often as a sh...
theres almost nothing decentralized about bluesky
Swapping Twitter for New Twitter.
Hey now, they’re happy to decentralize the feed management so they don’t have to worry about processing user’s custom feeds themselves!
Almost nothing decentralized yet…
You can host your own PDS (making it distributed but not decentralized), there is an ability to host a relay but hosting a relay requires mirroring the entire network instead of just subscribed nodes like AP, making it cost prohibitive for communities to organize their own relays on ATProto.
If bluesky is serious about decentralization then they need to make mirroring the entire network optional, allow relays’ firehoses to only to stream the activity from subscribed accounts from their users and federate with relays that don’t mirror the entire network.
Mirroring the entire network is what makes it a friendly experience for newcomers, IMO. In my own Mastodon instance I have to subscribe to a big relay (infosec.social) so that a reasonable proportion of replies from other instances I don’t happen to be happening populates into the feed.
I suppose you could say AP makes this optional, but that seems like a reasonable design choice to diverge on rather than a critical flaw in my opinion.
Mirroring the entire network is what makes it act like Twitter.
I’m not convinced that that’s A) something we should want, and B) a fight we can win. Trying to recreate what already exists, using technology that’s not really suited for it, feels like an uncanny skeuomorphism to me.
Really good points. I put some thoughts in this comment that I think reflect your concerns too. TL;DR the architectural differences lend suitability to the social differences as well between a Twitter-alike and a more clustered, less homogeneous social feed.
https://lemmy.sdf.org/comment/15918153
That definitely makes it accessible to newcomers. But costs are going to gatekeep smaller communities from hosting relays as the network scales. There are plenty of obscure conversations happening on the far corners of the network that don’t concern the majority, requiring a full network mirror of this activity just increases cost for minimal perceived benefit.
There does need to be some level of seeding, I think the big push for getting starter packs and the like into Mastodon is an example of that need. At the same time, it’s hard to justify spending the money on extra storage and computer just so I can see posts on furry bluesky or some other niche but highly active community.
That’s a good set of points and I agree. I am starting to think this technical difference reflects underlying social / experiential differences:
ActivityPub “clumpy” federation (like a region of city-states) where your view of the network is based on who you and others in your instance interact with - interoperability, but not homogeneity of content or interaction
Atproto “swarm” federation (like a pool of taxis sharing livery, with possibly-but-not-necessarily independent operators), endpoints are exchanging data to compose a single virtual platform out of replaceable interoperating parts - federated but not decentralized, having a primary network (the relay service) holding everyone’s experience together
To me the former feels like it encourages a spirit like original Internet communities (MUDs, BBSs, message boards) while the latter produces that of branded app platforms (Twitter, Facebook, Snapchat).