NIP-05 vs. DNS: Strategic mapping of sovereign identities on personal domains.
Posted: Wed May 13, 2026 12:15 am
NIP-05 vs. DNS: Strategic mapping of sovereign identities on personal domains
In the Nostr ecosystem, your public key (hex, or npub) is basically your “real” identity, but when it comes to actual person-to-person stuff the NIP-05 standard acts like a bridge over to the older DNS world. It does bring in a centralized-ish dependency (your domain registrar kinda sits there in the middle), still it gives you a strong path to claim a “sovereign handle” that you, and you alone, govern.
1. The Core Mechanism
NIP-05 turns a human readable identifier (example: satoshi@bitcoin.org) into a lookup prompt. When a client sees that handle, it reaches out and asks for:
https://bitcoin.org/.well-known/nostr.json?name=satoshi
Then the server hands back a JSON object. That object includes the public key tied to that name.
2. Why Bother With a Personal Domain?
A lot of newer folks grab free NIP-05 services like @nostrplebs.com or @getalby.com, and it works but it’s more like borrowing than owning. If those services go down, or decide to rewrite the rules, your verified status can evaporate without warning.
In this example we’re running our web server for Libretech work, it’s mostly a straight line.
Step A: Make the JSON File
Create a file called nostr.json. The shape should resemble this:
Step B: The .well-known Directory
Upload it so it lives on your server here:
/.well-known/nostr.json
Step C: CORS and permissions (mandatory-ish)
To let browser based clients fetch that JSON, you need Cross-Origin Resource Sharing (CORS) enabled. For Nginx you can add something like this:
4. DNS Fallback (NIP-05 via TXT Records)
Even though the JSON approach is the standard play, there’s still discussion around doing identity mapping with DNS TXT records directly, sorta like OpenAlias did. Yet for now, for broad client compatibility (Damus, Amethyst, Iris), the JSON-over-HTTPS method is still the main “practical discovery” route inside Nostr.
5. Discussion Points (for the Faculty of the Thread)
When you post your handle in The Lobby, add whether it is self-hosted. We want everyone in Hegemonikon to drift toward domain-verified sovereignty, step by step, even if it feels tedious at first.
In the Nostr ecosystem, your public key (hex, or npub) is basically your “real” identity, but when it comes to actual person-to-person stuff the NIP-05 standard acts like a bridge over to the older DNS world. It does bring in a centralized-ish dependency (your domain registrar kinda sits there in the middle), still it gives you a strong path to claim a “sovereign handle” that you, and you alone, govern.
1. The Core Mechanism
NIP-05 turns a human readable identifier (example: satoshi@bitcoin.org) into a lookup prompt. When a client sees that handle, it reaches out and asks for:
https://bitcoin.org/.well-known/nostr.json?name=satoshi
Then the server hands back a JSON object. That object includes the public key tied to that name.
2. Why Bother With a Personal Domain?
A lot of newer folks grab free NIP-05 services like @nostrplebs.com or @getalby.com, and it works but it’s more like borrowing than owning. If those services go down, or decide to rewrite the rules, your verified status can evaporate without warning.
- Sovereignty: If you serve the nostr.json file from your own setup (yourdomain.xyz or whatever), a third party can’t just yank permission away.
- Discovery: People can locate your npub when they already know your website.
- Credibility: It reads like you’re running infrastructure, not just consuming a platform.
In this example we’re running our web server for Libretech work, it’s mostly a straight line.
Step A: Make the JSON File
Create a file called nostr.json. The shape should resemble this:
Code: Select all
{
"names": {
"yourname": "your_hex_pubkey_here"
},
"relays": {
"your_hex_pubkey_here": [
"wss://relay.yourdomain.xyz",
"wss://nostr.mom"
]
}
}
Upload it so it lives on your server here:
/.well-known/nostr.json
Step C: CORS and permissions (mandatory-ish)
To let browser based clients fetch that JSON, you need Cross-Origin Resource Sharing (CORS) enabled. For Nginx you can add something like this:
Code: Select all
location /.well-known/nostr.json {
add_header Access-Control-Allow-Origin "*";
default_type application/json;
}
Even though the JSON approach is the standard play, there’s still discussion around doing identity mapping with DNS TXT records directly, sorta like OpenAlias did. Yet for now, for broad client compatibility (Damus, Amethyst, Iris), the JSON-over-HTTPS method is still the main “practical discovery” route inside Nostr.
5. Discussion Points (for the Faculty of the Thread)
- Are you hosting your nostr.json on something static like GitHub Pages/IPFS, or on a live VPS that actually moves fast?
- How are you thinking about the trade between DNS central control vs the convenience of human readable handles?
- Has anyone tested mapping a bunch of NIP-05 handles to the same key, for different “personae” within the same domain?
When you post your handle in The Lobby, add whether it is self-hosted. We want everyone in Hegemonikon to drift toward domain-verified sovereignty, step by step, even if it feels tedious at first.