What a handle change actually tells you
A Bluesky handle is a human-facing name. It can be changed, and it can be reassigned. The account identifier underneath it is a different thing, and that distinction is the whole basis of this task.
AT Protocol applications resolve a handle to a DID and use the DID as the canonical account identifier. Source
Because the DID is the identifier the system resolves to, a handle change alone does not establish that you are looking at a different account, and a matching handle does not establish that you are looking at the same one. The handle is a label; the DID is the anchor.
This matters when a familiar account appears under a new name, when an old handle suddenly points somewhere unfamiliar, or when you are trying to decide whether a public profile you saved last month is still the same account today. The task below is about recording evidence well enough to compare it later, not about proving who a person is.
Step 1: Capture the observation before you interpret it
Start by writing down what you actually saw, at the moment you saw it. Do not reconstruct it from memory afterwards.
- Observation date. Use a full date, not “recently.” Handle changes and reassignments are time-sensitive, and a comparison is only meaningful against a recorded point in time.
- Exact handle. Copy it character for character, including any domain-style suffix if one is shown. Do not normalise it, do not drop a prefix, and do not retype it from memory.
- DID if it is available. Copy the identifier exactly as displayed. Do not truncate it, and do not paraphrase it.
- The profile you were looking at. Note the display name and a one-line description of the profile content at that moment, so you can tell later whether the page itself changed.
- How you reached the page. A direct visit, a saved link, a search result or a shared post are different observation contexts and should be recorded separately.
If the DID is not visible to you at that moment, record that fact explicitly. “DID not available at observation” is a useful data point. An empty field that you fill in later from memory is not.
Step 2: Understand what resolution is doing
At a general level, a handle is resolved to a DID, and the DID is what the system treats as canonical. The DID document is the record that ties the identifier to its associated details.
DIDs provide stable account identifiers, while the DID document records the associated handle, signing key and hosting service. Source
You do not need to operate any particular menu or hidden search feature to use this concept. The practical point is narrower: when you compare two observations, compare the identifier, not the label. If you only have the label, you have a weaker comparison, and you should say so.
Step 3: Compare the two observations
Put the earlier and later records side by side and classify the result before drawing any conclusion. The decision table below is the core of this task.
| Evidence available | What it supports | What it does not support |
|---|---|---|
| Same DID, different handle | Account continuity is supported: the identifier is unchanged while the visible label moved. | It does not prove the person behind the account is the same human you assumed, and it does not prove any private detail. |
| Different DID, similar or identical handle | The handle now resolves to a different account identifier. Treat the earlier and later pages as separate accounts until other evidence says otherwise. | It does not prove the original account was deleted, renamed, sold or abandoned. |
| Handle present, DID unavailable in one or both records | Inconclusive. You have a label comparison only. | It does not support a continuity claim in either direction. |
| No record from the earlier observation | Nothing can be compared. Start a fresh record now. | It does not support any claim about what changed or when. |
Two habits keep this table honest. First, never upgrade an inconclusive row to a conclusion because the display name or photo looks familiar. Second, never treat a same-DID result as an identity verification. It is an account-continuity result, and nothing more.
Step 4: Run the self-review checklist
Before you act on a comparison, check your own work:
- Did I record a full observation date for each side of the comparison?
- Did I copy the handle exactly, including any suffix, rather than retyping it?
- Did I copy the DID exactly, or explicitly record that it was unavailable?
- Am I comparing identifiers, or am I comparing labels and calling it a match?
- Have I separated “same account identifier” from “same person” in my own notes?
- If the DIDs differ, have I avoided assuming the original account was deleted?
- If the evidence is inconclusive, have I written “inconclusive” rather than a guess?
- Have I kept the raw observation separate from my interpretation of it?
A comparison that fails any of the first four checks should be treated as a lead to re-check, not a finding.
Common mistakes
Treating a handle as a permanent address. Handles change and can be reassigned. A saved link to a handle is a link to a label, not to an identifier.
Assuming a rename means a new owner. A visible handle change with the same DID is the ordinary continuity case. A different DID under a similar handle is the reassignment case. They look alike from the outside and mean different things.
Assuming a different DID means the old account was deleted. It only means the handle now resolves to a different identifier. Deletion is a separate question that this comparison does not answer.
Filling in a missing DID later from memory. A reconstructed identifier is not an observation. Record the gap instead.
Letting a matching photo or biography do the work. Matching photos, biographies and handles cannot independently prove identity. They are corroborating details at best, and they are easy to copy.
Skipping the date. Without a timestamp, two records cannot be ordered, and an unordered comparison cannot support a continuity claim.
Protecting your own footprint
If you are on the other side of this task, the same mechanics apply to you. Your visible handle is a label that others may record and compare, and your identifier is the anchor that persists across a handle change. That has two practical consequences.
First, expect that a handle change will be noticed and compared by anyone who saved your earlier profile. If you want continuity to be legible, keep your public profile details consistent across the change so that a reader comparing records has something stable to work with. Second, remember that public matches are leads. Someone comparing your old and new handle can establish that the identifier is unchanged, but they cannot establish who you are from public identifiers alone, and neither can a tool.
Periodically review your own known public handles and record what is currently visible, so that you have your own dated baseline rather than relying on someone else’s notes. If you want a starting point, TraceSeek offers a free first scan across 3,000+ platforms, with results typically returned in 20-30 seconds. That scan reviews public username matches; it does not change platform settings, guarantee a match, or verify identity. Treat its output the same way you would treat your own observations: as a dated lead to check, not a conclusion.
For how we frame evidence and its limits, see our methodology notes, and for the mechanics of changing a visible handle, see the existing guide on setting a Bluesky domain handle and updating your public links.
Key facts
- AT Protocol applications resolve a handle to a DID and use the DID as the canonical account identifier.
- DIDs provide stable account identifiers, while the DID document records the associated handle, signing key and hosting service.
- A visible handle change with an unchanged DID supports account continuity, while a different DID under the same handle means the label now points to a different account identifier.
- Matching photos, biographies and handles cannot independently prove identity, so a shared public identifier is a lead rather than proof of who is behind an account.
- A handle comparison made without a recorded DID is inconclusive and should not be presented as a continuity finding.