threenine.io
How to self host your NIP 05 Identity

How to self host your NIP 05 Identity

seleft

Gary WoodfineGary Woodfine Dec 15, 2025

Self-hosting your NIP-05 identity represents the pinnacle of digital sovereignty in the Nostr ecosystem, placing you in complete control of your online persona rather than entrusting it to a third-party provider. By running your own verification server, you eliminate single points of failure, ensure your identity cannot be arbitrarily censored or suspended, and gain the freedom to modify your identifier at will without dependency on external services. This approach not only enhances privacy by keeping your verification records private but also reinforces the decentralised ethos that Nostr was built upon, making it the ideal choice for users who prioritise autonomy, security, and true ownership of their digital presence.

Why Self Host your NIP 05 Identity

Self-hosting your NIP-05 is fundamentally important because it transforms your online identity from a rented service into a permanently owned asset, which is the core principle of a truly decentralised network like Nostr.

Here's a breakdown of why it's so crucial:

1. True Ownership and Control When you use a third-party NIP-05 provider, you are essentially borrowing an identifier. Your _username@provider.com exists at their discretion. If that service goes offline, changes its business model, or decides to ban you, you lose your verified identity. Self-hosting with your own domain (e.g., you@yourdomain.com) means you and only you control that identity. No one can take it away from you.

2. Censorship Resistance Third-party providers are centralised points of control. They can be pressured to de-platform users or may enforce their own terms of service. A self-hosted NIP-05 has no such central authority. As the operator of your own server, you are the final arbiter of what content is associated with your identity. This is critical for preserving free speech in a censorship-resistant environment.

3. Enhanced Privacy and Security When you use a provider, you are trusting them with the association between your Nostr public key and your chosen identifier. They hold this data and could be compelled to share it or could have a data breach. Self-hosting keeps this information on your own infrastructure, giving you full control over its security and access. You aren't adding another entity to your trust chain.

4. Permanent and Persistent Identity Your domain is a long-term asset you control. By linking it to your Nostr identity, you create a permanent, memorable identifier that is intrinsically tied to you. This isn't just a fleeting username on a service; it's a durable part of your digital identity that will last as long as you maintain your domain and server.

5. Upholding the Decentralised Ethos The entire point of Nostr is to move away from centralised points of failure and control. Relying on a centralised NIP-05 provider works directly against this principle. By self-hosting, you are contributing to the strength and resilience of the network, reducing its reliance on trusted third parties, and embodying the self-sovereignty that makes Nostr revolutionary.

Why are NIP 05 Identifiers Important

NIP-05, also known as "Mapped Names to Public Keys," is a Nostr Improvement Proposal that provides a human-readable verification system for Nostr identities. It solves the problem of having to remember long, cumbersome public keys (like npub1l2vyh47mk2p0qlsku7hg0vn29s9s0q03yfwsydlr9gqth7de5zqsq2ancs) by linking them to simple, internet-style identifiers (like jack@jack.gg).

The system works by using a simple DNS-based lookup mechanism, similar to how email works. Here is the step-by-step process:

1. The User's Identifier

A user claims an identifier in the format of local_part@domain. The local_part is the username you choose, and the domain is a web domain you control or that is provided by a service.

2. The Well-Known File

The owner of the domain must create and host a JSON file on their web server. This file must be publicly accessible at a specific URL: https://<domain>/.well-known/nostr.json

This JSON file acts as the "phonebook" or "directory" for that domain, mapping the local_part to a Nostr public key. A basic file looks like this:

{
  "names": {
    "jack": "npub1zc0e...mxf0v"
  }
}

In this example, the identifier jack@jack.gg is mapped to the specified Nostr public key (npub...).

3. The Verification Process

When a Nostr client (an app or website) sees an identifier like gary@somedomain.com, it performs the following steps to verify it:

  1. Parse the Identifier: The client splits the identifier into its two parts: the local_part ("gary") and the domain ("somedomain.com").
  2. Fetch the JSON File: The client makes an HTTP request to https://somedomain.com/.well-known/nostr.json.
  3. Look Up the Public Key: The client receives the JSON file and looks inside the "names" object for the key that matches the local_part ("gary").
    1. Verify the Match: It retrieves the corresponding public key value from the file. The client then checks if this public key matches the public key of the Nostr account that is claiming the gary@somedomain.com identifier.
  4. Display the Checkmark: If the keys match, the client displays a verification checkmark next to the user's name. This proves that the user legitimately controls that Nostr account.

Optional: Pointer to Relays

NIP-05 also allows the domain owner to specify recommended relay servers for a user within the same JSON file. This is done using a relays object. When a user like bob@example.com sends a message, clients can look up this file to know which relays to publish it to.

Example with relays:

{
  "names": {
    "bob": "npub182m...m3qrh"
  },
  "relays": {
    "npub182m...m3qrh": [
      "wss://relay1.example.com",
      "wss://relay2.example.com"
    ]
  }
}

In essence, NIP-05 is an elegant and decentralised bridge between the established Domain Name System (DNS) and the Nostr public key infrastructure. It leverages the ubiquity of DNS and simple web hosting to create a user-friendly verification layer without requiring any new, complex protocols.