NIP-05 makes Nostr identities easier to recognize by mapping a public key to a DNS-based identifier.
What it standardizes
It lets a profile publish an identifier such as name@example.com and lets clients verify that the domain maps the name back to the public key.
- Protocol layer. NIP-05 is not a consumer product. It is a convention that clients, relays or adjacent services may choose to support.
- Interoperability. The value is not that every app looks the same. The value is that different apps can understand the same signed data.
- Optionality. NIPs are implementation possibilities. Builders should implement the pieces that serve their product, security model and user journey.
Implementation notes
A domain serves a nostr.json file under .well-known. Clients check the name and public-key mapping before displaying the identifier as verified.
- Client responsibility. Clients need to explain the feature clearly because the user sees an experience, not a spec.
- Relay responsibility. Relays may support only the parts that fit their storage, moderation, authentication and business model.
- Indexing responsibility. Search, discovery and context often require extra indexers or opinionated clients on top of the raw protocol.
Crays relevance
Crays can use domain-backed identifiers for creators, venues, Association accounts and ecosystem services so users can recognize official identities.
- Crays.net. Profiles, creator pages and social proof need portable identity rather than a closed account table.
- Crays World. Real venues need local context, member state, reputation and payments that can survive app changes.
- DAO path. Future governance needs signed identity, membership context and auditable participation signals.
Risks and design discipline
NIP-05 does not custody the key. If a domain is compromised or a private key is stolen, users still need clear recovery and communication practices.
- Do not overpromise. A NIP gives a shared format. It does not magically solve onboarding, moderation, UX or custody.
- Keep the private key away. Any feature that increases private-key exposure increases the attack surface.
- Use plain language. Most users need outcomes: login, pay, publish, vote, prove status, access a venue.