On Bluesky, the handle and profile details can change over time, while the underlying account identifier (the DID) is meant to stay attached to the same account. If you have a voluntarily shared public account, you can note the DID, handle and profile metadata as three separate observations. Continuity of the DID shows the account record persisted; it does not confirm who the person is offline.
Find public social profile clues with our TraceSeek app.
Separate the three layers you are comparing
Treat a public Bluesky account as having at least three layers worth recording separately: a stable account identifier (the DID), a human-readable handle, and mutable profile metadata such as display name and avatar. The protocol is designed so the DID is stable while the handle and profile details can be updated. Keeping these on separate lines stops a change in one layer from being misread as a change in another. [Bluesky Protocol Services: resolving identities]
What continuity of the DID can and cannot mean
A stable account identifier supports a continuity check: you can ask whether the account record you looked at before is the same record you are looking at now. That is a statement about an account on the protocol, not about a person. It does not prove a person's offline identity, and it cannot tell you who sent a separate message elsewhere, such as a dating chat. The claim to make is narrow: this account record persisted. [Bluesky Protocol Services: resolving identities]
Record your comparison before drawing conclusions
Write down what you actually observed and what you are entitled to observe. Use only a public account or an account the owner has voluntarily shared. Do not attempt to access a private account, and do not try to identify a person from similarity or to contact strangers. If the artifact you expected is not visible, mark it unavailable and stop rather than pushing past the access boundary.
- Note the DID exactly as shown, without retyping from memory
- Note the handle exactly, including the full domain
- Note profile details only as metadata, not as verified facts
- Mark any layer you cannot see as unavailable
A worksheet for account-continuity review
The table below keeps observations, their limits and your next practical step in separate columns. Fill it in only from what you can see on the shared public account.
| observation | limit | next step |
|---|---|---|
| Stable account identifier (DID) is present and unchanged between your two views | Shows the account record persisted; says nothing about offline identity | Record it as continuity of the account only |
| Handle differs between views | A handle is updatable, so this alone is not a new account | Compare the DID before concluding anything changed |
| Profile display name or avatar differs | Profile metadata is mutable and easy to edit | Treat it as presentation, not identity proof |
Decide what to do with an unclear result
If the DID, handle or profile layer is missing or you cannot view the account, the honest result is unavailability. Use the platform's current official help for how identifiers and handles are displayed, or ask the owner for a voluntary current link rather than guessing. Do not upgrade a protocol-level continuity finding into a claim about cheating, intent or safety. [Bluesky Protocol Services: resolving identities]
A couple more questions
If the handle changed but the DID did not, is it a different account?
Not on the DID alone. The handle is designed to be updatable while the account identifier stays stable, so a handle change with the same DID points to continuity of the account record. It still tells you nothing about offline identity.
Does a stable DID prove who sent me a message elsewhere?
No. A stable account identifier supports account continuity on the protocol. It is not proof of a person's offline identity and does not establish who sent a separate message on another service.
What should I do if I cannot see the account or its identifier?
Record the layer as unavailable and stop at the access boundary. Use the platform's current official help or ask the owner for a voluntary current link instead of trying to access a private account.
Sources & editorial notes
Official references checked on October 23, 2026. Checklists, comparison tables and example wording are DateClues editorial tools, not official tests or validated risk scores.
General information. No guide or tool can certify a person’s identity, intentions or safety. Read our editorial standards.