There Are No Instances in ATProto
This post dives deep into the architectural distinctions of ATProto, the protocol behind Bluesky, challenging the common misconception that it operates with "instances" like Mastodon. The author, a prominent voice in web development, clarifies that ATProto separates data hosting from application logic, likening it to RSS feeds and readers, which sparked a lively debate on decentralization, moderation, and the practicalities of building federated social networks. It resonated with the Hacker News community's ongoing interest in open protocols and the future of social media.
The Lowdown
Dan Abramov's post, "There Are No Instances in ATProto," addresses a recurring question on Hacker News: "But where are all the Bluesky instances?" He argues that this question stems from a "Mastodon-brained concept" and fundamentally misunderstands ATProto's architecture, which decentralizes differently by separating content hosting from content aggregation applications.
- RSS Analogy: Abramov begins by recalling the "golden age of the web" with RSS, where users published content on their own blogs (hosting) and aggregated it via apps like Google Reader (aggregation). He emphasizes that hosting and aggregation were distinct, a concept central to ATProto.
- Centralization's Pitfall: He contrasts this with traditional social media like Facebook, where hosting and aggregation are bundled, leading to centralization and its associated problems.
- Mastodon's Instance Model: Mastodon's approach to decentralization involves "instances," which are self-hostable, bundled hosting+app servers. This model leads to identity being tied to an instance, potential issues with defederation between instances, and O(n^2) scaling challenges for inter-instance communication.
- ATProto's Separation of Concerns: ATProto returns to the RSS model: users own their data and host it on Personal Data Servers (PDS), which are separate from the applications (AppViews) that aggregate and present this content. This allows users to swap hosting providers or use different applications without losing their identity or data.
- User Agency in Decentralization: The article highlights that ATProto offers user agency through the ability to migrate hosting (e.g., to Eurosky or self-host on Cloudflare) and to create or use diverse applications (like Tangled or Semble) independently of each other. The author's own app, Sidetrail, is presented as an example.
- Misconceptions about Relays: Abramov clarifies that Relays, often mistaken for ATProto's "instances," are merely optional performance optimizations for data distribution, not fundamental architectural components. They are cheap to run and not essential for an app to function.
In conclusion, Abramov asserts that "counting Bluesky instances" is misleading. ATProto's decentralization is about the fundamental separation of hosting and applications, offering a richer, more flexible structure where users maintain control over their data and identity, free from the constraints of bundled "instances."
The Gossip
Centralization Conundrums
The discussion heavily debated the true decentralization of ATProto. Critics argued that despite its architectural design, ATProto still exhibits centralized points, particularly the single PLC directory and the perceived dominance of Bluesky PBC. Concerns were raised about the practical feasibility and incentives for individuals to run their own AppViews or Relays, leading some to conclude that, in practice, ATProto could become as centralized as traditional platforms. The author and supporters countered by explaining the PLC's planned independent governance and the low cost/effort of running various independent components.
Relay Realities & Architectural Elucidations
Many commenters questioned the author's initial omission and subsequent explanation of 'Relays,' suggesting it downplayed their importance or hinted at a hidden centralization point. The author clarified that Relays are primarily performance optimizations, not core architectural 'instances,' and that applications can function without them by querying other caches. He emphasized their low cost and the existence of community-run options, aiming to demystify their role in the network's structure.
Moderation Modalities & Data Ownership
The article's explanation of ATProto's separated hosting and app layers sparked debate on moderation. Commenters asked how ATProto handles issues like content censorship or defederation, comparing it to Mastodon's approach. The author explained that moderation occurs at different layers: hosting providers can ban illegal content, and app providers moderate content displayed in their specific apps, allowing users to switch apps or hosting if they disagree with moderation policies. Some worried about the 'scraping is the default' nature leading to less control over content dissemination.
Analogous Appraisals & Authorial Assertions
A portion of the discussion focused on the author's tone and choice of analogies. Some found the 'Mastodon-brained' phrase and subtle criticisms of ActivityPub unnecessarily divisive, arguing it detracted from legitimate technical comparisons. The use of Google Reader as an analogy for ATProto's aggregation model also drew criticism, with commenters pointing out its eventual shutdown and the subsequent negative impact on RSS communities, raising concerns about similar centralization risks for ATProto. The author defended his tone as necessary to address common misunderstandings.