Most answers to this stop at "who issued the claim." That's half the problem.
In a centralized model, one party plays two roles at once: it stores your identity data, and it decides who gets to read or verify it. Those two roles being the same party is the actual thing "decentralized" is trying to remove — not the data's physical location, the coupling between storage and permission.
When the party holding your identity data is also the party that controls readability, that party can revoke, alter, or quietly change what's visible about you, and you have no independent way to check — because checking would require going through the same party you're trying to check. This isn't a hypothetical: platforms suspend accounts, change verification policy, or shut down, and whatever "identity" you had there goes with them.
Formally: topology (where the data runs) and audience (who can read it) collapse into one controller — the same structural failure argued from Byzantine fault tolerance in The Byzantine Prompt.
Most decentralized identity work — W3C Decentralized Identifiers (DIDs), Verifiable Credentials, blockchain-anchored public keys, self-sovereign identity wallets — solves a specific, real problem well: who issued this claim, and can I verify their signature without asking them again. That's a genuine, useful decentralization — it removes a central issuer as a single point of failure for verification.
What most of that same tooling leaves as a separate, bolted-on layer is a different question: who can read the underlying data in the first place. A signed credential is usually still stored somewhere, readable by whoever has access to that storage, with access control handled by a policy layer sitting beside the data — not by the data's own structure.
.me Adds to This
.me treats readability itself as the thing to decentralize,
not just issuance. Audience membership is declared as a structural,
cryptographic property of a path — using a single operator,
_ — rather than a permission checked by a separate policy
layer:
me.identity["_"]("scope-key");
me.identity.claim("verified-human");
me("identity") // undefined — root stays invisible
me("identity.claim") // readable only with the effective keyTopology — where the encrypted bytes physically live or replicate — and audience — who can derive the key to read them — are independent variables. Replicating the ciphertext to a new host, a backup, or another device never expands who can read it. Formal treatment: The Algebra of Encrypted Audiences; the composable version across multiple identities: Encrypted Semantic Island.
| "Who issued this?" | "Who can read this?" | |
|---|---|---|
| Typical DID / VC tooling | Solved — signature verification | Usually a separate access-control layer |
.me | Not its focus | Solved — audience is structural, enforced by decryption itself |
These are complementary, not competing — a system could use verifiable
credentials for issuance and .me's audience model for
readability. The point isn't that one replaces the other; it's that
"decentralized identity" usually means only the first column, and the
second one matters just as much.
Decentralized identity, taken to its actual conclusion, isn't only "the user owns their data." It's an inversion of which thing is the center.
Platform-centric: User → Platform → World
.me-centric: World → .me → MeaningToday, almost every digital action starts with a verb aimed at a platform: open Instagram, open Gmail, open GitHub. Each platform defines, unilaterally, what exists inside it, how it relates, and what it means. The user enters as a visitor inside someone else's universe, every time.
A user-centric system reverses the direction: identity — .me
— is the fixed center, and platforms become implementations that
connect into that center, not destinations the user travels to.
Instagram, GitHub, a chat log — each becomes a node related to the
user's own graph, not a separate universe the user has to re-enter and
re-orient inside of every time.
Formal version of this statement, with the structural basis and the honest boundary spelled out precisely: The User-Centric System.
This isn't only a metaphor — part of it is a direct consequence of how
.me paths work, already verified in
Inverted Dependency Indexing: the
kernel starts from me.whatever.you.want("x") — free-form
declaration, not a fixed schema owned by a platform. Combined with the
containment order established in
SpaceStructure
(q ≤ p ⟺ q is a descendant of p), a person's own graph —
family, work, music, the AI systems they talk to — is addressable by
meaning, not assigned by whichever app happens to hold the data:
me
├─ family.photos
├─ family.messages
├─ work.neurons_me
├─ work.github
├─ music.playlists
└─ ai.claudeEach branch exists because it means something to the person who declared it — not because a platform shipped a menu item for it.
Being precise about the gap matters here as much as anywhere else on
this site: resolving a path like me://self:read/family.photos
across a mesh of surfaces is real, specified behavior — the
Namespace Resolution
Protocol does exactly that, hop by hop, without a central registry.
Turning a natural-language request like "show me what Ana posted" into
that resolved path is not something NRP or the kernel does today — that
layer is intent, not shipped mechanism. The honest claim is narrower:
the addressable, meaning-first graph a natural-language layer would sit
on top of is real and resolvable now; the natural-language layer itself
is the direction, not a current feature.
A platform-centric system optimizes one question: how do we keep this person here longer. A user-centric system optimizes a different one: what is this person actually trying to do. That's not a branding difference — it changes what the incentive structure rewards. One architecture is built to maximize time inside a boundary it controls; the other is built to resolve a request and let the person move on.
_/~ mechanism, source-verified.