Why the AT Protocol DID Is the Identity Bluesky Never Loses

What is an AT Protocol DID?

Every Bluesky account carries an AT Protocol DID, a persistent identifier that the AT Protocol assigns once and never reassigns to a different account. The protocol's own specification calls the DID the "primary account identifier in atproto," built on the W3C decentralized identifier standard, and a typical one looks like did:plc:ewvi7nxzyoun6zhxrhs64oiz. Treat the DID as the account's real name and the handle as a nickname that can change around it.

What are did:plc and did:web, and how are they different?

AT Protocol supports exactly two DID methods, did:plc and did:web, and each resolves an identifier to an account's data in a different way. did:plc is a method built specifically for AT Protocol and is self-authenticating, meaning the identifier itself carries enough cryptographic information to verify its own history without trusting a central authority beyond the directory that hosts it. did:web is a W3C community method that ties the identifier directly to a hostname over HTTPS, which means the account's identity now depends on that domain staying under the same owner's control.

What is the PLC directory and who runs it?

The PLC directory is a public, free registry that resolves did:plc identifiers to their current DID documents, and Bluesky Social PBC built and operates it as infrastructure for the wider AT Protocol network, not as a Bluesky-only service. The directory describes itself as "strongly consistent, recoverable, and allows for key rotation," using self-certifying operation logs that anyone can verify cryptographically rather than a blockchain or token system. As of October 2024, the directory hosted more than twelve million registered identifiers, according to its own documentation.

How does a DID differ from a Bluesky handle?

A DID is the stable identifier that never changes, while a handle is a human readable, DNS-based username that Bluesky's own protocol guide explicitly treats as reassignable. The protocol's design goal is that identities stay "portable across services," so changing a provider or a domain "should not cause a user to lose their identity, social graph, or content." The handle is what people see and type, but every follow, post and interaction on the backend still points to the DID underneath it.

Why can a handle change while the DID stays the same?

A handle can change because it functions as a pointer to the account, not as the account's actual address, so updating a domain name handle or switching hosting providers only rewrites the pointer, not the identity it points to. A user who verifies a custom domain as their handle, then later gives up that domain, can update their handle again without losing followers, posts or history, because every one of those records was tied to the DID all along. This separation is the same reason a bluesky app password can be revoked and reissued without touching the account's underlying identity: revocation changes access credentials, not the account itself.

How do you resolve an AT Protocol DID in practice?

Resolving a DID means turning a handle into a DID and then turning that DID into a full DID document, and AT Protocol's own guide lays out both steps. Handle to DID resolution works through a DNS TXT record at _atproto.<handle> or through an HTTPS well-known endpoint on the handle's domain. Once you have the DID itself, a did:plc resolves through a plain HTTP GET to the PLC directory, such as https://plc.directory/did:plc:ewvi7nxzyoun6zhxrhs64oiz, while a did:web resolves through the hosting domain directly. Either path returns a DID document listing the account's current handle, signing key and the URL of the personal data server hosting its content.

Why does this matter for tracking Bluesky accounts over time?

DIDs matter for tracking Bluesky accounts over time because a handle-only record breaks the moment someone renames their account, while a DID-based record keeps pointing at the same account no matter how many times the handle changes. Any tool built on social media data collection across Bluesky should resolve and store the DID alongside the handle, not the handle alone, or historical mentions and follower data will silently disconnect from accounts that rebrand their handle later. RedReplier's Bluesky monitoring tracks mentions at the account level for exactly this reason, so a tracked conversation stays attributed to the right account even after a handle change.

Frequently Asked Questions

Can a Bluesky account have more than one DID?

No. Each Bluesky account is created with exactly one DID that stays fixed for the life of that account, and switching between did:plc and did:web is not a supported operation once an account exists on one method.

What happens to a DID if someone deletes their Bluesky account?

The DID document can be marked as tombstoned or deactivated depending on the DID method, but the identifier itself is not reassigned to a new account afterward. A deleted account's DID does not become available for someone else to claim.

Is a did:web account less secure than a did:plc account?

Not inherently less secure, but did:web ties account continuity to keeping control of a specific domain, with no built-in recovery path if that domain is lost, while did:plc supports key rotation and recovery through the PLC directory's own mechanisms. The tradeoff is domain independence against built-in recoverability.

Do I need to understand DIDs to use Bluesky as a regular user?

No. Bluesky's interface only shows handles during normal use, and the DID resolution happens automatically behind the scenes. Understanding DIDs matters mainly for developers, researchers and anyone building tools on top of the AT Protocol.

Can I look up any Bluesky account's DID myself?

Yes. Resolving a handle to its DID uses a DNS TXT lookup or an HTTPS well-known request, both of which are public and require no special access, and the PLC directory itself is a public, queryable service for did:plc accounts.

Does changing a Bluesky handle affect search results for that account?

Search behavior depends on how a given tool indexes accounts, but AT Protocol itself resolves mentions and follows through the DID, not the handle, so a well built bluesky search operators implementation should keep returning results for an account after it changes its handle.

What does an AT Protocol DID actually look like?

An AT Protocol DID follows the format did:plc:... or did:web:..., built on the W3C decentralized identifier standard. A working example from the protocol's own documentation is did:plc:ewvi7nxzyoun6zhxrhs64oiz. The prefix names the method that assigned it, plc or web, and everything after it is either a generated string or a hostname.

What information is stored in a DID document?

A DID document lists the account's current handle, its signing key, and the URL of the personal data server hosting its content. Resolving a DID, through the PLC directory for did:plc or through the hosting domain for did:web, returns this document. The PDS address inside it is what a client uses to actually fetch an account's posts and data.

Why does AT Protocol support two different DID methods instead of one?

AT Protocol supports did:plc and did:web because they trade off different things. did:plc is self-authenticating and lets an account recover through key rotation on the PLC directory, while did:web gives full ownership of the identifier to whoever controls a domain, with no built-in recovery if that domain is lost. Offering both lets an account holder choose portability and recoverability, or domain independence, based on what matters more to them.

How many accounts does the PLC directory have on record?

As of October 2024, the PLC directory's own documentation listed more than twelve million registered identifiers. Bluesky Social PBC operates the directory as infrastructure for the wider AT Protocol network, not as a service limited to its own app. The directory uses self-certifying operation logs that anyone can verify cryptographically, with no blockchain or token system involved.