Reply on Bluesky and Decentralization - bryan newbold

"a reply to Christine Lemmer-Webber's thoughtful ... "How decentralized is Bluesky really?", Hubbed earlier, which "raises the bar on analysis in this space. However, I disagree with some of the analysis".

First, agreement with CLW's "shared heap" image, and a good summary of how Bluesky works: "atproto is a global self-authenticating network: a single gigantic heap. Accounts have global identifiers (DIDs), which they use to publish data (repos and records)... into an intertwingled ocean of public graph data: records with AT-URI references to other records. Applications are "views" of that global data graph... the "huge public heap" concept is pretty baked-in... facilitates big-world indices... not cheap at scale!"

Why do that? Because "mass public networking has an important role in society", complementing "smaller more densely-connected communities... where folks should probably spend the majority of their hours."

That needs "a "zero compromises" user experience... all the performance, affordances, and consistency of using a centralized platform."

Also, they're inevitable (cf Gordon Brander), which will lead to network capture "if they aren't planned for from the start". They're doing that to "keep the network resilient and interoperable even when (not if!) the largest tech companies in the world get involved".

Apparently the Fediverse has had possible moves in this direction for some time -cf "recent Fediverse Discovery Providers initiative ... the possibly growing role of ActivityPub relays".

So they didnt set out to create a p2p network where people can run nodes with a Raspberry Pi, but Bluesky "is designed to ensure "credible exit", adversarial interop, and other properties, for each component ... [which] might require collective (not individual) resources" to run. This is not just for companies - many non-profit orgs have demonstrated "the capacity to run larger services", while "communities with different visions and priorities could also build alternative dataflows... The ability to scale-down atproto is similar to the ability to scale-up ActivityPub to mega-instances like Threads... there might be a bit of friction, but it is possible." Moreover, it's designed to allow communities to "start small, with server needs proportional to the size of their sub-network."

He declines to get involved in a terminology debate, preferring to set out Bluesky's high-level goals and ask where he can find "an equivalent set of design goals for ActivityPub or [CLW's]Spritely", but does "defend the use of certain terms to describe our work to date. So: is atproto "decentralized"? Is Bluesky "federated"?... it is fair to say a system is or isn't federated or decentralized until it has been in a material sense", and right now everything's centred around Bluesky: it's PDSs, PDS software, relay, app and Lexicons (application schemas).

But does the "network architecture facilitates and lends itself to a "decentralized" or "federated" outcome"?

While "atproto maybe doesn't meet Christine's definition of decentralization: power is not diffused evenly throughout", he turns to a different definition and finds it does: "Every major infrastructure component can be substituted without undo friction. There are significant design features to prevent capture, control, or extraction of rent of the overall atproto network." Similarly for federation: "many hosts, each with multiple accounts, all interoperating... a point on a spectrum between peer-to-peer and fully-centralized", although it doesn't follow common federation patterns. He concludes that "federation isn't the best term for Bluesky to emphasize going forward".

He does explicitly acknowledge some points by CLW: DM, key management, public content, relay hosting costs, etc. In all cases work is being done.

But he contests statements like "Bluesky will always have control over that user's key, and thus their identity future." Not so: those "who created accounts on the Bluesky PDS instances, then migrated to their own self-hosted instance, no longer have any Bluesky-controlled rotation keys in their identities."