NIP-05 (Nostr Identifier)

NIP-05 is the Nostr standard for tying a raw public key to a human-readable, DNS-backed identifier shaped like name@domain.com. A user puts a nip05 field in their profile metadata (the kind 0 event), and clients verify that the claim is genuine by checking the domain itself rather than trusting the label at face value. It exists because 64-character hex keys are unreadable and unmemorable: NIP-05 gives people something they can print on a business card while keeping the cryptographic key as the actual identity.

How verification works

When a client encounters a NIP-05 identifier it splits it into the local part and the domain, then performs a GET request to https://domain.com/.well-known/nostr.json?name=<local-part>. The server returns a JSON object whose names map pairs identifiers with lowercase-hex public keys. If the key returned for that name matches the pubkey on the user's metadata event, the identifier is confirmed and the client shows a verification mark. The endpoint must not issue HTTP redirects, and clients ignore any they receive, which keeps the verification path unambiguous. The file can also include a relays map suggesting where each key's events can be found — a useful discovery hint. By convention _@domain.com is the root identifier and clients display it simply as the domain.

What it proves — and what it doesn't

NIP-05 is verification, not naming ownership: it proves that whoever controls the domain vouches for that key, nothing more. Your identity remains the keypair — the npub/nsec pair — and the identifier is a label attached to it, not a login. That direction matters: if you lose the domain, you keep your key, your followers, and your history; only the label breaks. Contrast a platform handle, where losing the account is losing everything. The trust anchor is DNS and the web PKI, so it inherits their weaknesses — a compromised domain or registrar can vouch for an attacker's key — which is why the verification mark should be read as "this domain endorses this key," never as proof of a person. Big shared-hosting providers can vouch for thousands of names, which is convenient and exactly as centralized as it sounds.

Running your own

Hosting NIP-05 yourself is one of the cheapest pieces of sovereign infrastructure you can stand up: a domain you control and one static JSON file at /.well-known/nostr.json (with CORS enabled so browser clients can fetch it). No database, no daemon, no third party — it will happily sit next to anything else you self-host, including your own Nostr relay. The pattern mirrors Lightning Address, which resolves the same name@domain shape to a payment endpoint, and pairs naturally with a NIP-07 browser signer keeping the private key out of every web client. D-Central documents NIP-05 for Bitcoiners building identity they own end to end: same keys-first logic as self-custody, applied to your name. A worthwhile detail when setting it up: verification failures are usually mundane — a missing CORS header, an accidental redirect from a www-to-apex rewrite, or an uppercase character in the hex pubkey — so test the raw URL in a browser before blaming the client. And because the JSON file is served fresh on every check, rotating which key your name vouches for is instant: change the file, and every client's next lookup sees the new binding. That immediacy is a quiet advantage over identity systems that bake bindings into slow-moving registries. Add the file, verify it from a second device, and you have joined the small set of people whose online name resolves to infrastructure they actually control — a ten-minute job that permanently removes one more intermediary from your identity.