The Bluesky Federation Paradigm

🧵 [1 / 12]

#Bluesky ’s latest blogpost [1] reveals that the #ATProtocol is a classic bait and switch game, facilitated by the small-world/big-world distinction. [2]

The bait is telling creators that their content is safe (from petty moderators/server shutdown) and that they are not locked into a platform because the AT protocol is federated, so they can self host with a handle under their control. The switch is that the (federated aspect of the) AT Protocol is irrelevant in the big-world.

🧵 [2 / 12]

In the small-world/big-world paradigm, the AT protocol answers only one question: “where is my content stored?” The answer it provides is (from a technical point of view) needlessly complex and distracts from the more important question: “how is my content discovered?”

🧵 [3 / 12]

A PDS (Personal Data Server) is pretty similar to a Wordpress blog: anyone who knows where it is hosted, can browse it’s contents. But to let the world know about its existence, an external indexing service is required. In the Bluesky vision, this service consists of BGS (Big Graph Service), Labeler, AppView and FeedGen. Together, these components form the “big world” which resembles a traditional search engine, crawling the web for content.

🧵 [4 / 12]

The “Federation Architecture Overview” [1] mentions that independent big worlds could co-exist and hints that a big world may be decomposed (e.g. a BGS operator might outsource the Labeler). This allows for calling Bluesky decentralized, in the sense of a technical system that has built-in redundancies as fail-safes to guard against outages. But in the context of walled gardens, the important question to ask is, if the platform is also decentralized on the organizational level.

🧵 [5 / 12]

The core component of a big-world is the BGS, a crawler that aggregates content from all PDS into a single stream which is then consumed by subsequent services. Aggregation is a centralization pattern and since each big world contains exactly one of these funnels, they too become inherently centralized, i.e. whoever controls the BGS firehose also controls what content exists (in the big world). This reduces the role of a PDS to a file server, storing backup copies.

🧵 [6 / 12]

Technically, a big-world moderator may not be able delete content in a self hosted PDS, but cutting it off from the feed has the same effect: content that cannot be found may as well not exist.

🧵 [7 / 12]

Creators have to go where the audience is and the audience goes where the content can be found. Bluesky’s own big-world has the following competitive advantages:

🧵 [8 / 12]

• It is the first one to exist, allowing it to sponge up all early adopters.
• It is the first one to exist, giving it a headstart at building an index.
• A large portion of the content will be hosted on Bluesky servers, allowing it to use more efficient crawling methods and/or thwart emerging competition by charging for API access and/or imposing rate limits.

🧵 [9 / 12]

In a social network, users tend to gravitate towards the largest service. Building another big-world in the microblogging nice means an uphill competition with Bluesky for users. Building in a different niche (e.g. vblogging) means Bluesky can cannibalize thanks to the common protocol. Either way it is unlikely for another big-world to grow in the shadow of Bluesky and even less likely that it wouldn’t try to dominate, if it did.

🧵 [10 / 12]

Content consumers get bound into a big-world through the AppViews service, which needs to store their preferences for feed generation (a mobile phone will obviously not connect directly to a BGS to filter the stream). Creators get bound by their need to optimize content for the lexicon [3] of big-world with the largest audience (i.e. the microblogging lexicon, monopolized by Bluesky).

🧵 [11 / 12]

On paper, Bluesky may appear as an open system, but it can (and therefore will) be parameterized into being yet another walled garden.

🧵 [12 / 12]

Sources:

1. https://blueskyweb.xyz/blog/5-5-2023-federation-architecture
2. https://atproto.com/guides/overview#achieving-scale
3. https://atproto.com/guides/lexicon