ATProto and the End of the Instance-Based Social Network

The fundamental difference between ATProto and federated networks like Mastodon is that ATProto removes the concept of the "instance." While users often ask where the "Bluesky instances" are, this is a category error; ATProto is designed to decouple data hosting from the application layer, allowing users to swap hosting providers or use different apps without losing their identity or social graph.

Decoupling Hosting from Aggregation

ATProto operates on a principle similar to the early web's RSS and Google Reader model. In that ecosystem, content lived on individual blogs (hosting) and was aggregated into readers like Google Reader or Feedly (apps). The hosting and the aggregation were two separate functions.

Traditional social media centralized these functions into a single "box," where the app and the hosting were inseparable. Federated networks, such as those using ActivityPub (e.g., Mastodon), attempted to decentralize this by creating many smaller versions of that box—called "instances." In the Mastodon model, a user belongs to a specific instance, and their identity is tied to that instance's domain (e.g., user@instance.com). If that instance shuts down or the admins stop federating with other servers, the user's identity and connectivity are compromised.

ATProto erases this box. It treats the network as a collection of hosting providers (Personal Data Servers or PDS) and independent apps that aggregate data from those providers. This allows for a richer form of decentralization:

• Hosting Portability: Users can migrate their data from one PDS to another without changing their handle or losing their followers.
• App Independence: Users can use any app that implements the protocol to view the "Atmosphere" of data, meaning the Bluesky app is just one of many possible projections of the network.

The Role of Relays and AppViews

To make this decoupled architecture performant, ATProto utilizes Relays and AppViews. Relays act as the glue of the system, shuttling data from PDSes to AppViews, which then filter and shape the content for the end user. This separation allows each component to scale independently according to its specific demands.

However, this architecture has led to technical and philosophical debates within the community:

"As far as I can tell, Relays are the glue that makes ATProto work performantly... the big improvement vs Mastodon is that Relays, AppViews and PDSes are separate services with their own distinct scaling demands."

Critical Perspectives on ATProto's Decentralization

Despite the theoretical flexibility of the protocol, critics argue that the current implementation remains highly centralized in practice. Several key points of contention have been raised:

Practical Centralization

Many observers note that Bluesky PBC currently runs the primary app, hosts the majority of user data, and operates the main relays. This creates a situation where the system is decentralized at the protocol level but centralized in operation. Some argue that the PDS is effectively an "instance" by another name, as it remains the canonical source of truth for a user's data.

The "Google Reader" Risk

The analogy to Google Reader is viewed by some as a warning. While RSS survived the shutdown of Google Reader, the social graphs and community structures built within that centralized aggregator were destroyed. Critics suggest that if the network becomes overly dependent on a few large AppViews or Relays, it risks the same fate.

Moderation and Defederation

Unlike the Mastodon model, where instance admins can "defederate" (block) other instances to protect their community, ATProto's design prioritizes a global firehose of data. This shift moves the focus of moderation from the server level to the user or app level, which some argue removes necessary "membranes" that protect smaller communities from harassment or toxicity.

Economic Sustainability

There are concerns regarding the cost of running the infrastructure. While hosting a PDS is relatively inexpensive, running high-performance Relays and AppViews is costly. This raises questions about the long-term business model and whether the network can survive without venture capital funding, unlike the more cooperative or non-profit funding models seen in the Fediverse.