BlueSky brand identity has two layers: the human-friendly handle people see and the persistent DID that the protocol uses to identify the account. Handles can change. A DID is the durable identifier that schedulers, clients, PDSes, and AppViews should treat as the stable account identity.
For brands, that distinction matters during rebrands, custom-domain handle changes, PDS migrations, and recovery events. A clean audit starts by reading the DID document and, for did:plc accounts, the public PLC operation history.
Read the DID PLC reference implementation overview for the method's rotation-key model and transparent operation log.
What the PLC directory records
The DID PLC method is designed around recoverable, cryptographically controlled identity updates. The public reference describes rotation keys that sign update operations, each operation referencing the prior identity state by hash, with a central directory server validating operations and maintaining a transparent log for each DID.
That log is not the same thing as a BlueSky content archive. It is an identity-operation history. It helps answer questions like which handle was claimed, which PDS endpoint was advertised, which signing key was current, and whether the identity changed during a migration.
Fields to inspect in the current DID document
- id: confirms the DID document is for the DID you resolved.
- alsoKnownAs: lists the claimed handle URI, usually at://handle.example.
- verificationMethod: exposes the current public atproto signing key.
- service: identifies the current AtprotoPersonalDataServer endpoint.
- rotation keys: appear in PLC operations and matter for identity recovery and future updates.
Review the AT Protocol DID specification for the fields clients should parse from DID documents.
Why handle history needs bidirectional checks
The handle specification requires a handle to resolve to a DID and the DID document to claim that handle. That bidirectional check prevents a stale DNS record, outdated domain handle, or cached identity response from being treated as authoritative without verification.
For a brand, the audit question is not just 'what is the handle today?' It is 'did the handle, DID document, PDS endpoint, and account-control keys tell a consistent story at the time we scheduled and published content?'
A practical brand-history audit
- Resolve the current handle to a DID.
- Open the current DID document and confirm alsoKnownAs, signing key, and PDS endpoint.
- If the DID is did:plc, inspect the PLC directory history for identity operations.
- Record handle changes, PDS endpoint changes, and recovery or rotation events.
- Compare those events against scheduled campaigns, launch windows, and public brand announcements.
Use the BlueSky DID and PLC directory lookup helper to normalize handles, validate DID syntax, and open the public resolver links before a brand audit begins.
Where ONYX fits
The operational rule for ONYX is simple: schedule against the account identity you have verified, keep the public handle visible for humans, and review identity changes before major campaigns go live.
When a brand changes handles or migrates account infrastructure, the content calendar should not turn into guesswork. Keep launches, queued posts, source links, approval notes, and identity checks together so the team can see which posts were approved under which account state.
Use the BlueSky content calendar template to keep identity-sensitive campaigns visible during rebrands or PDS work.