What Is the AT Protocol and How Bluesky Handles Work

When you type a Bluesky handle like jack.bsky.social into a viewer and it instantly loads that person's posts, a lot of machinery is working behind the scenes. That machinery is the AT Protocol, the open protocol that Bluesky is built on. This article explains what the AT Protocol is, what its main pieces do, and why it matters for how you browse Bluesky content.

What Problem Does the AT Protocol Solve?

Traditional social networks are walled gardens. Your account, your posts, and your follower list all live on one company's servers. If that company changes its rules, sells the platform, or bans your account, you lose everything. You cannot take your identity or your audience somewhere else.

The AT Protocol (short for Authenticated Transfer Protocol) was designed to solve exactly this. It makes three things possible that a closed network cannot offer:

• Portable identity: Your account is not tied to one server. You can move it and keep your followers.
• Portable data: Your posts and data belong to you and can be taken with you or re-hosted.
• Open interconnection: Different services can talk to each other over the same protocol, like email providers do.

Bluesky Social is the most popular app built on this protocol, but the protocol itself is open, which is why tools like this viewer can read Bluesky data without special permission.

The Four Main Pieces

The AT Protocol has several components, but four of them are the ones that matter most for understanding how a handle becomes a set of posts on your screen.

1. The DID (Decentralized Identifier)

Every account has a DID, which looks something like did:plc:abcdef123.... This is the true, permanent identity of the account. It is cryptographic and does not change when the user switches servers or changes their handle. Think of the DID as the social security number of the account, it follows the person everywhere.

2. The Handle

The handle is the human-readable name, like name.bsky.social or a custom domain like name.com. Handles are easier to remember than DIDs, but they are really just a pointer. Behind the scenes, a handle resolves to the underlying DID. When you search for a handle in this viewer, the first thing the protocol does is resolve that handle to a DID so it can find the account's data.

This is also why custom-domain handles matter. If you see a handle like alice.example.com, the protocol verified that the owner of example.com authorized that handle, which gives you extra confidence the account is genuinely controlled by that domain.

3. The PDS (Personal Data Server)

The PDS is where an account's data actually lives: posts, likes, follows, profile info, and media references. Bluesky Social runs the largest PDS, which is why most .bsky.social accounts live there. But the protocol is designed so that other organizations or individuals can run their own PDS too. Because your identity is your DID rather than your server, you can move from one PDS to another and your followers still find you.

When this viewer fetches someone's posts, it is effectively reading from the PDS that hosts that account (via the relay, described next).

4. The Relay and AppView

Reading directly from every individual PDS would be slow and complicated. The protocol includes relays (sometimes called firehoses) that aggregate public data from all PDSes into a single stream, and an AppView that lets clients query that aggregated data efficiently. When you search a handle and immediately see posts, the viewer is talking to an AppView that has indexed the relayed data so it can answer queries like "give me this user's recent posts" or "who follows this user?".

This split between PDS (storage), relay (aggregation), and AppView (query) is a big part of why the protocol stays open and fast while still allowing portability.

What Happens When You Search a Handle

Putting it all together, here is what happens in the fraction of a second between typing a handle and seeing posts:

1. The viewer resolves your handle to its permanent DID.
2. Using the DID, it finds which PDS hosts the account.
3. It queries the AppView for that account's profile, posts, follows, and followers.
4. The AppView returns the indexed data, and the viewer renders the profile and timeline you see.

All of this works without you logging in because the data being fetched is public by design. The protocol treats posts, follows, and profile metadata as openly readable, which is the whole reason anonymous viewing tools can exist.

Why This Matters for Readers

For most readers, you do not need to remember what a DID or a PDS is. But understanding the shape of the protocol helps explain a few practical things:

• Why anonymous viewing works: Public data is openly queryable over the protocol, so a viewer does not need your login to show you public posts.
• Why likes are different: Likes are treated as more sensitive than posts and follows, so they are not as freely available, which is why some viewing tools cannot show a full likes list.
• Why handles can look different: Some users have .bsky.social handles (hosted on Bluesky's PDS) and others have custom domains (verified by domain ownership). Both are valid and both resolve to a DID the same way.
• Why the network is resilient: Because no single company controls all the pieces, the protocol can outlive any one operator.

A Helpful Analogy

If this still feels abstract, think of it like email. You have an email address (the handle), which points to a mailbox (the PDS). Different providers can host different mailboxes, but they can all send mail to each other because they speak the same protocol. Your address does not change who you are if you switch providers, and anyone can look up a public directory (the AppView) to find where to reach you. The AT Protocol aims to bring that same openness to social media.