ATProto for Distributed Systems Engineers: How Bluesky's Protocol Reimagines Social Infrastructure

Bluesky's AT Protocol is more than just a Twitter alternative, according to a technical deep dive written for distributed systems engineers. The new protocol reimagines social platforms from the ground up, challenging conventional web architecture. The article starts by describing the scaling issues of traditional web apps, which rely on a single SQL database.

As the user base grows, the database becomes expensive to maintain due to strong consistency requirements. This leads to a trade-off between eventual consistency and the ability to perform JOINs and aggregations.

To solve this problem, ATProto uses a federated model where each user has their own data store, or repository, which they control. Each repository is cryptographically signed and can be hosted anywhere. Users can move their data between providers without losing their identity or content. ATProto embraces eventual consistency and uses relays to aggregate public data from all user repositories into a firehose. This creates a market for data aggregation rather than a monopoly.

The protocol separates the app view, which indexes and queries the relay data, from the personal data store, allowing multiple app views to exist on the same data. This means that different app types, such as Twitter-like, Reddit-like, and Instagram-like apps, can all run on the same underlying data. The decentralized nature of ATProto solves several problems faced by centralized social networks.

Users are not locked to a platform, making identity and content portable. Moderation becomes scalable, with anyone able to run a labeling service that users can subscribe to. Competition is fostered through a market of frontends, allowing better Twitter clients to exist without requiring users to migrate.

However, ATProto is not without its trade-offs. The lack of global ordering means that there is no canonical ordering of posts, which can break features like trending that depend on a global view. Eventual consistency can be hard to reason about, especially when users expect instant feedback. Running a relay at scale requires significant infrastructure, potentially leading to centralization.

Building on ATProto is also more complex than building on a centralized API, requiring a deep understanding of repositories, relays, and app views.

While ATProto is often compared to ActivityPub, the protocol behind Mastodon, the key difference lies in how servers communicate. ActivityPub requires direct server-to-server communication, creating a mesh of connections that can be fragile. ATProto separates the data, aggregation, and presentation into distinct layers, allowing each layer to be optimized independently. The analogy to DNS is apt, as ATProto is more like a hierarchical system with distinct roles, each serving a specific function.