Dan Abramov Explains Why ATProto Has No 'Instances' — And Why That Matters for Decentralized Social
Tags OSS · Infrastructure · Decentralized Social · Protocol Design
Dan Abramov, React core team member and Bluesky team engineer, published a detailed technical explanation of why the ATProto protocol (which powers Bluesky) does not have 'instances' in the Mastodon/ActivityPub sense. The post clarifies that ATProto uses a relay-based architecture where user data lives in personal data servers (PDS) that can be self-hosted or hosted by providers, but the network topology is fundamentally different from ActivityPub's federated server model. The explanation addresses a persistent source of confusion in the decentralized social media community, where users accustomed to Mastodon's instance-based model incorrectly assume Bluesky has equivalent server-level federation.
Technical significance
The architectural distinction Abramov explains has practical implications for developers building on ATProto: there is no server-level moderation boundary equivalent to a Mastodon instance, which means content moderation and community governance must be implemented at the application layer (via labelers and feed algorithms) rather than at the network layer. This design choice trades the simplicity of instance-level governance for greater flexibility in how moderation is composed, but it also means Bluesky's decentralization is more nuanced than 'just run your own server.'