Let's start with a question that sounds simple and turns out not to be: what is your username, really?

You think of it as yours. But pause on the word yours. Your email address belongs to a mail provider. Your handle on a social network belongs to that network. Your phone number is leased to you by a carrier. Each of these is an identifier a company assigned to you — and what one party assigns, that same party can suspend, reclaim, sell, or simply turn off. You don't own those names. You rent them, and the landlord keeps the keys.

Here's the difference, in one picture. Most logins are a hotel room key card. It opens your door today, but the front desk encoded it, the front desk can wipe it, and the moment they decide otherwise it's a dead piece of plastic. What NAOMS gives you is a key you cut yourself, to a lock only you control — and anyone can check it really is yours just by looking, without phoning the hotel to ask. Hold those two keys side by side; the rest of this article is the difference between them.

There's a different way to build an identifier. It's called a decentralized identifier, or DID, and it sits underneath every identity in NAOMS. This article is a patient walk through what that means and why it matters. No prior crypto knowledge needed — just bring the username question with you.

The shape of the problem

When you log in somewhere today, two things happen that you rarely separate in your mind:

1. You name yourself ("I am alice@example.com").
2. Some server vouches that the name is really yours, because it holds your account record.

The trouble is step 2. The vouching is done by an authority — and the whole arrangement only works as long as that authority exists, agrees with you, and stays online. If the company folds, if your account is flagged, if the server is unreachable, your identity evaporates. Not because anything about you changed, but because the thing that was speaking on your behalf went quiet.

A decentralized identifier flips this around. The goal is an identifier where the proof of ownership travels with the identifier itself, so no third party needs to vouch. You name yourself, and anyone can check the name is yours by doing math — not by asking a server's permission.

A self-certifying name

Here's the trick at the heart of it, and it's genuinely elegant.

When you create a NAOMS identity, your device generates a cryptographic key pair: a private key it keeps secret, and a public key it can show the world. Then it writes down a tiny first record — call it the birth certificate of the identity — that says "this identity begins now, controlled by this public key." It takes a fingerprint (a hash) of that birth certificate, and embeds that fingerprint into the identifier itself.

The identifier ends up looking roughly like this:

did:webvh:<fingerprint>:<where-to-find-the-log>

That embedded fingerprint is called a self-certifying identifier — self-certifying because the name proves its own origin. Anyone who has your identifier and your birth-certificate record can recompute the fingerprint and check it matches. If it matches, they know this log is the genuine history of this exact identity. No registry. No central database. The identifier carries its own proof.

This is the part worth sitting with: the identifier resolves to nobody's server. It resolves to a verifiable record that you control, and the verification is something each person can do for themselves with nothing but the same math.

"did:webvh" — the method NAOMS chose

DIDs come in many flavours, called methods. NAOMS uses one named did:webvh — "web, with verifiable history." It was an honest integration choice rather than an invention: a published specification and a small open-source library already did this well, and reusing proven work is better than reinventing identity from scratch (getting identity wrong is how you ruin people's lives).

What did:webvh gives you out of the box is worth naming plainly:

• Verifiable history. Your identity isn't a single frozen fact — it's an append-only log. Each change (a key rotation, a new device, a deactivation) is a new entry that links back to the previous one, like beads on a string. Anyone can replay the string from the birth certificate forward and confirm every step was authorized by the key that was valid at that moment.
• Pre-rotation. You can commit now to the key you'll rotate to later, before you ever use it. So even if your current key is one day compromised, an attacker can't hijack your identity's future — the next rightful key was already promised in the chain.
• Deactivation that's honest about itself. You can retire an identity, and resolving it afterward returns a clear "deactivated" status rather than a confusing silence or a dead link.
• Offline-first. Because the log can be cached locally, you can resolve and verify an identity without being online. Optional web publication exists for discoverability, but it is never the thing that makes the identity real. The cryptography does that.

That last point is the soul of it. A NAOMS identity does not depend on any server being reachable to be valid. Reachability is a convenience. Validity is math.

An identity for more than people

NAOMS makes one more move that we find quietly radical. In most systems, "identity" means "a human's account." But the original purpose behind this work asks a wider question: what if every being — human, agent, river, collective — could prove who they are without asking anyone's permission?

So a NAOMS DID document carries a being-type. An identifier can declare itself as a human, an agent (an AI acting on someone's behalf), a collective (a group), or a non-human entity. The plumbing is the same self-certifying log in every case. What differs is only the label the identity wears, and what it's allowed to do. An agent you delegate to gets its own real, verifiable identifier — not a borrowed one, not a shared password — with its authority scoped and revocable.

When "who am I?" had three answers

We want to be honest about the messy middle, because the clean story above was earned, not given.

Early on, the running system had three different internal ways of answering "who is the owner of this device?" They queried different tables, and under certain timing they could disagree — one might return the real cryptographic identifier while another fell back to a raw device ID. When that happened, a thing you created under one name became invisible to an operation that looked you up under another. The symptom was maddeningly indirect: you'd be told you weren't an admin of a space you yourself had just made.

The fix was not clever; it was disciplined. Collapse the three paths into one resolution function, called once when the system starts, with a clear cascade of where to look — and a firm rule that it never returns an empty string or a device ID as if it were your identity. One authoritative answer to "who am I?", computed the same way every time. Identity systems fail at the seams between their own answers, and the cure is to have fewer answers.

So, what did you actually get?

Both pieces above — the original did:webvh integration and the later unification of resolution — shipped and reached their finished state in the project. What you have as a NAOMS user is:

• An identifier you generated, that nobody assigned and nobody can revoke from the outside.
• Proof of ownership that travels with the identifier, checkable by anyone, online or off.
• A verifiable history of your identity's life, with safe key rotation built in.
• The same machinery extended honestly to agents and collectives, not just people.

Go back to the hotel key one last time. The difference between a rented room card and a key you cut yourself isn't something you'd notice on a good day — when servers are up and companies are friendly, both open the door. The difference shows up on the bad day: the outage, the ban, the shutdown, the dispute. On the bad day, a rented identity is at the mercy of the front desk. A self-certifying one answers only to math, and the math doesn't take sides.

That's the whole point. An identity that resolves to nobody's server is an identity nobody can take away.

Written by AI agents from real project logs; owned and edited by Mujo.