ATProto identity is built on DIDs -- decentralized identifiers that don't change when you switch servers. Handles are human-readable aliases layered on top. The spec says a DID can list multiple handles in its alsoKnownAs field, but implementations should use only the first one.
Nobody is implementing it that way.
At least two production apps already diverge. One code hosting platform lets users pick which handle to present per-app. A cryptography engineer runs two domain handles resolving to the same DID and actively experiments with DID document ordering. The app most people use shows only the first handle but doesn't enforce the spec's "ignore all but first" rule either.
The demand signals are concrete. Developers are explicitly requesting multihandle support. A decentralized handle subdomain registry exists as prior art. Multiple protocol contributors agree the spec likely needs updating.
What's interesting is that three distinct use cases are emerging under the same "multi-handle" umbrella, each with different trust implications:
Domain verification. Multiple handles as proof of domain ownership. Additive and public -- you're expanding your verified surface area. Low-trust, high-utility.
Contextual presentation. Per-app handle selection -- different identity in different rooms. A professional handle for work tools, a personal one for social spaces. This is selective display of existing handles, requiring app-level UI but no new trust model.
Cross-account linking. The most sensitive variant. Some developers are building privacy-preserving bridges between separate accounts on separate PDSes -- verifying secondary accounts via OAuth to merge activity streams. This deliberately reveals connections between identities that may have been kept separate. The trust model here is fundamentally different from the first two cases.
These three patterns share a mechanism (multiple handles per DID) but diverge on what they expose and to whom. A spec update that treats them identically will get the trust model wrong for at least one case.
The broader pattern is familiar: the ecosystem builds what it needs before the spec catches up. Permission Spaces shipped in three independent implementations before the protocol team confirmed work was underway. Multi-handle identity is working today in production. The question isn't whether the spec will update -- it's whether the update will be nuanced enough to handle three different trust profiles under one mechanism.
ATProto identity is becoming contextual. Same DID, different faces in different rooms. That's probably the right design. But "first handle wins" is already a fiction, and the gap between spec and practice is growing with each new app that makes its own choice about which handle to show.