My last post in this blog was in 2019. A lot has changed in the last 6 years. In the meantime, I have been posting on the mico-blogging platform Bluesky and I have been fascinated by the technology behind it. My new handle at Bluesky is @georgeck.me.
In the post, I want to share my understanding of the technology behind Bluesky, the ATProto.
ATProto (Authenticated Transfer Protocol) is an open, decentralized network for building social applications and is the technology underpinning Bluesky. In essence, ATProto defines how a decentralized social network operates, handling identity, data storage, and communication between servers. Its design addresses many challenges of social media: improving user experience, interoperability, content discovery, scalability, and portability of user data and social graphs. Bluesky Social was created as a proof-of-concept built on ATProto and remains the flagship service in this ecosystem. Below we dive into ATProto’s architecture and features, and how Bluesky leverages them for a richer user experience.
Decentralized Federation: ATProto uses a federated model, meaning the network is composed of multiple servers rather than one central platform. Personal Data Servers (PDS) host user accounts and data, while Big Graph Servers (BGS) (often called relays) index content (likes, follows, posts) and handle discovery like search and feeds. This separation improves scalability and reliability. For users, it feels like one social network, but under the hood your data can live on your chosen server while still interacting with the wider network. Federation was chosen to keep the network convenient and available while preventing any single server from being a bottleneck.
OK - let's take a break and understand the terms used in the above paragraph. As a member of decentralized social network, I own the data I create and share. To fully own my data, it needs to be stored in a server that I control. This is where the Personal Data Server (PDS) comes in. I could run my PDS in my home server or as a droplet in Digital Ocean. For most users, running a PDS is not practical. BlueSky provides a default PDS for all users. In my example, if you look at my profile, you will see that my PDS is hosted at https://morel.us-east.host.bsky.network.
So, if our data is all distributed, how does Bluesky manage to create a feed that shows all the posts from the people I follow? This is where the Big Graph Server (BGS) or Relays comes in. The BGS indexes all the data from all the PDSs produce a firehose of change events. Bluesky has the notion of AppView, that consumes these changes and creates a feed that is shown to the user. Let's explore this further with the analogy of an RSS reader. As a user, you can create a custom RSS feed that shows all the posts from the people you follow. As a content creator, I can create my blog on a server that I own. I also share my blog as an RSS feed. If you subscribe to my feed in your RSS reader, you will see all the posts I create. The RSS reader is the AppView in the Bluesky world.
p.s. Did you know that the default PDS provided by Bluesky uses SQLite to store the data? This is a great example of SQLite DB-per-tenant pattern. You can read more about this here.
Decentralized Identity (DIDs): Identity on ATProto is handled via domain handles and DIDs (Decentralized Identifiers). Users can have usernames that look like domain names (e.g. georgeck.me), which map to a cryptographic DID URL for that account. The DID is essentially a secure identifier that remains server-agnostic, so your identity isn’t tied to one specific server. This enables account portability: you could move your account to a different server (or host your own) without losing your identity, followers, or content. The protocol’s goal is to let a user migrate to a new server seamlessly if their current PDS shuts down or if they just choose to switch. All your data is stored in a signed data repository attached to your DID (like a personal git repo of your posts and interactions), which can be verified independently of any single server. In practical terms, this means you own your social data and handle, which is a big shift from traditional platforms.
Here is the DID document for my handle @georgeck.me.
{"@context": ["https://www.w3.org/ns/did/v1","https://w3id.org/security/multikey/v1","https://w3id.org/security/suites/secp256k1-2019/v1"],"alsoKnownAs": ["at://georgeck.me"],"id": "did:plc:44jes5cerb74g62otttber65","service": [{"id": "#atproto_pds","serviceEndpoint": "https://morel.us-east.host.bsky.network","type": "AtprotoPersonalDataServer"}],"verificationMethod": [{"controller": "did:plc:44jes5cerb74g62otttber65","id": "did:plc:44jes5cerb74g62otttber65#atproto","publicKeyMultibase": "zQ3shNEV63JbvA1pwzi9oJ82FjnqqvogUYbRypxjwS94hmB7f","type": "Multikey"}]}
Data Repositories and Lexicon: All content on ATProto – posts, likes, follows, etc. – lives in each user’s personal data repository as signed records. These are cryptographically signed by your account, ensuring authenticity. To make different apps and servers understand each other’s data, ATProto uses a schema system called Lexicon. The Lexicon defines standard data types and API methods (called “lexicons”) that everyone follows. For example, there’s a schema for a basic post (app.bsky.feed.post) that defines it must have text and a timestamp. Because of this global schema network, software from different developers or communities can interoperate – a Bluesky app and another ATProto app will speak the same language. This interop design gives client apps the freedom to innovate on user interface and features without breaking compatibility. In other words, ATProto is modular: identity, data storage, and app logic are separated into components, rather than one monolithic service.
To give a concrete example, here is the lexicon for my first post in Bluesky.
{"uri": "at://did:plc:44jes5cerb74g62otttber65/app.bsky.feed.post/3kfa7zyrteb25","cid": "bafyreidgbqqpwq6yezpet4xzbitll7iarlfbhcoe6mjtpfmbyik4jog3am","value": {"text": "1/5\n\"Content is King\" - The Old SEO Adage:...","$type": "app.bsky.feed.post","langs": ["en"],"createdAt": "2023-11-28T07:38:07.581Z"}}
So, coming back to the RSS reader analogy, the RSS feed will have a standard format that all the RSS readers understand. This is the Lexicon in the Bluesky world.
Algorithmic Choice: A novel feature of ATProto is support for algorithmic choice. Users are not locked into one ranking algorithm for their feed. Instead, feeds and content discovery can be provided by third-party services that anyone can build or choose. Your PDS will route feed requests to your chosen algorithm provider. For example, you might pick a feed generator that shows only tech-related posts, or one that prioritizes your close friends – or stick with the default “What’s Hot” feed. This opens the door for a marketplace of algorithms where users have control over what content gets amplified to them. It’s akin to choosing your own search engine for social content. While this feature is still emerging, it’s a powerful idea for user engagement: people can select feeds that they find most engaging or relevant, rather than everyone being subject to the same one-size-fits-all algorithm.
Moderation Model (Speech vs. Reach): ATProto separates speech and reach into different layers. The base layer (speech) is the personal data repo where you can post anything allowed by your server – it’s about giving everyone a voice. The reach layer comes from indexing services (like the BGS relays or custom feeds) that aggregate and promote content. By decoupling these, ATProto makes moderation more flexible: content that violates rules can be down-ranked or filtered in feeds (reducing its reach) even if it remains in the user’s personal dataset. This design aims to support free expression while still enabling healthy curation of what spreads widely. In Bluesky, this is complemented by community labeling and moderation tools (like user-set filters and block lists) to balance open speech with safe, curated reach.
Summary of Benefits: In practice, ATProto’s architecture means a Bluesky user enjoys ownership of their account, cross-app portability, and a say in their content experience. The network can scale (via distributed servers) while remaining open. The use of standard schemas ensures any new app or feature plugs into the existing ecosystem, encouraging a vibrant developer community. For end users, features like being able to use your own domain as your handle, or potentially taking your followers with you to a new server, are game-changers for engagement and trust on the platform.
ATProto is a powerful framework for building decentralized social networks. The "Atmosphere" is the term we use to describe the ecosystem around the AT Protocol. It’s designed to be modular, scalable, and user-centric, with a focus on interoperability and data ownership. Bluesky Social is a great example of how ATProto can be used to create a rich social experience - let's engage in the "Atmosphere" together!