Beyond Instances: How atproto Decouples Data from Apps

atproto does not use instances like Mastodon, but instead decouples data hosting from application aggregation. This architecture mirrors the RSS model, where independent data is projected through various apps, allowing for true user portability. Ultimately, the author argues that atproto's decentralization is found in the ability to swap hosts and build diverse apps on a shared data layer.

Key Points

• Mastodon's instance model bundles hosting and application, making user identity dependent on specific servers and admin relationships.
• atproto separates hosting from aggregation, allowing users to own their data independently of the apps they use to view it.
• The atproto model is analogous to the golden age of RSS, where blogs were hosted independently and aggregated by various readers.
• User identity in atproto is portable, meaning moving to a different host does not destroy a user's social presence or handle.
• Decentralization in atproto is achieved through host swapping and the creation of diverse, interoperable applications rather than federated server clusters.

Sentiment

The overall sentiment is mixed and somewhat skeptical. The community largely understands and often accepts the article's architectural point that atproto is not organized around Mastodon-style instances, but many readers do not accept that this settles the decentralization debate. The dominant mood is constructive disagreement: technically curious, appreciative of the explanation in places, but wary of the framing and focused on practical bottlenecks around AppViews, moderation, and Bluesky's current infrastructure.

In Agreement

• Atproto's PDS layer is not equivalent to a Mastodon instance because it hosts user repositories while applications aggregate, rank, moderate, and present that data separately.
• The article's RSS and reader analogy helps explain why asking for Bluesky instances can confuse app deployments with the underlying portable data layer.
• Separating identity and data from applications can make migration less destructive than ActivityPub systems where identity, hosting, and app behavior are bundled together.
• Relays can be useful infrastructure, but they are not the central architectural idea; the key model is the split between hosting and apps.
• The broader atproto ecosystem shows that multiple application types can share the same user identity and data substrate rather than being limited to a Twitter-like client.
• ActivityPub-style moderation and defederation can create fragmented community politics, while atproto may let users keep identity and content while choosing different application or moderation layers.

Opposed

• The article's tone is seen by many as needlessly dismissive of ActivityPub users and as turning a reasonable decentralization question into a terminology scolding.
• Critics argue that AppViews function like the practical instance from a user's perspective because they determine visibility, moderation, feeds, and the usable social experience.
• Several commenters say the article is incomplete because it leaves relays and AppViews out of the core diagrams even though they matter for real-world independence.
• Skeptics distinguish protocol decentralization from Bluesky decentralization, arguing that the current social network still depends heavily on Bluesky-operated infrastructure.
• Owning or moving a PDS may not help if other people cannot see the user's posts through the dominant AppView or moderation stack.
• Some commenters prefer ActivityPub's community-governed instances because they provide visible independent moderation boundaries and may be less aligned with public-by-default scraping.