A small minimal guide on setting up NIP-05 identifier on branle/nostr

NIP-05_Simple_Guide.md

This is a very basic guide, just to understand what's needed to set it up.
If you have any questions you can find me at https://nostr.com/8355095016fddbe31fcf1453b26f613553e9758cf2263e190eac8fd96a3d3de9

Prerequisite

• a webserver with a domain under your control
• nostr account with private and public key setup on https://nostr.com, preferably set up with nos2x: https://github.com/fiatjaf/nos2x

Setup static file on server

Create a file that resolves to <domain>/.well-known/nostr.json, and fill it out like this (enter the name you want to use, and input your own public key, make sure its the HEX-key):

{
  "names": {
    "<name>": "<pubkey>"
  }
}

Setup CORS permissions

For branle to be able to execute the file, you have to allow CORS on your webserver.
On nginx you just have to put this in the config:

add_header 'Access-Control-Allow-Origin' '*';

Setup branle/nostr

In branle, go to settings and fill inn your <name>@<your topdomain> in the "NIP-05 Identifier" field.

Go you your profile. If everything worked out, you will see a checkmark next to your name (based on your domain).

Extra tools

• NIP-05 Creation Tool: Use this to generate the .well-known/nostr.json file, and also a .htaccess file for Apache if you don't use Nginx

Usual problems

• CORS: Make sure CORS is correctly set up. You can test it here: https://www.test-cors.org/
• Pub-key: Only use the HEX-key. Npub-key won't work.

The extra level of abstraction also means I have portability - which is very important: If you just create "markjr" @ caughq.org and then shut down (or cancel me), then everything pointing at my now defunct nip05 id is bust and I have to start all over again with a new id. (It's no different than having your Twitter handle suspended.)

With the additional abstraction layer in there, I just create a new account at a new provider and update my DNS TXT record.

The NIP-05 spec specifically addresses this portability issue by stating that once resolved, clients MUST manage follows with the pubkey, not the NIP-05 identifier. This way if the identifier breaks, only the identifier is no longer valid. You don't lose all of your followers or anything like that:

https://github.com/nostr-protocol/nips/blob/master/05.md#clients-must-always-follow-public-keys-not-nip-05-addresses

Perhaps I sounded too literal when I said "like an email address". I know this isn't email, but my point was that email addresses are formatted that way for a reason - they are user @ organization - and they wouldn't have became the de facto standard if they didn't have that additional level of abstraction at the organization level which was implemented via the MX RRType in DNS.

They're user@domain, because they were originally intended to point to users of various systems. SSH users that connect to other systems with the user@system convention understand this well. Organizations may have many domains (and sub-domains) and may use one of their root domains that maps clearly to their identity for mail and other services, but that's an abstraction that has simply just become commonplace. A lot of organizations still use the www sub-domain for web services, for example, even though the website is clearly the organization's primary brand website, so I see where you're coming from with the user@organization point.

In the case of NIP-05 however, the organization (through the domain) is simply vouching for identities. There is no other association implied by providing this domain validation. The more technical of us will of course set up validation on our own domains, but the vast majority of Nostr users will use a validation provider to vouch for their identity, with varying levels of verification. So far, these users don't seem to care too much about using these as organizational identifiers other than some vanity points for being verified by the "cool" domain, like NostrPlebs.com (Everyone wants to be a pleb, right? (:

I think you and I are in the tiny minority who will go out of their way to try and map their NIP-05 verification to their own organizational identity.

i ve change my webserver's setup and how long supposed time i should wait for the verifaction process take again?

i ve change my webserver's setup and how long supposed time i should wait for the verifaction process take again?

it should work right away, depending on how the client handles it.
does it work in astral.ninja ?

If you're going to tie a label like an email address to a pubkey, why not just use the DNS to create the linkage as well (I've been having a similar conversation with the lnURL people) - with well-known file paths, you need access to the webserver, the webserver may not be the same host as the hostname component of the email identifier, not to mention, what do do you do when you want to switch servers but retain the same identifier?

You could use scoped TXT records like _nip05 to signal your pubkey:

Given test@example.com:

$ORIGIN example.com.
_nip05.test IN TXT “<pubkey>”
_nip05url.text IN TXT "http://<domain>.well-known/nostr.json"

The first record _nip05 would just be a straight reference to the pubkey.

There could also be a reference type for the well-known file URI, but you get the added flexibility that the file doesn't have to reside on the same webserver as example.com.

See: andrerfneves/lightning-address#27 (comment)

And I also wrote this article:

https://bitcoinmagazine.com/technical/simplifying-bitcoin-addresses-dns

Similar to the way DNSLink works for IPFS

I think you and I are in the tiny minority who will go out of their way to try and map their NIP-05 verification to their own organizational identity.

I don't know if this will be a tiny minority.

Also, from your other reply:

The NIP-05 spec specifically addresses this portability issue by stating that once resolved, clients MUST manage follows with the pubkey, not the NIP-05 identifier. This way if the identifier breaks, only the identifier is no longer valid. You don't lose all of your followers or anything like that:

Thanks for pointing this out - it's good to know.

However, consider this: let's say Nostr really catches on to the point where people are putting their NIP-05 id's in their .sig files. social media handles and stone-age business cards - it doesn't help if a third-party provider goes away or cancels you, all those indelible references to your old NIP-05 break (it's exactly the same with IP addresses, after all).

In any case, I'm working on a NIP-05 ID server that will work for custom domains. We'll see if there's any demand for it.

In case you need to convert your Damus Npub to Hex https://nstr.cloud/key.html

If you're going to tie a label like an email address to a pubkey, why not just use the DNS to create the linkage as well (I've been having a similar conversation with the lnURL people) - with well-known file paths, you need access to the webserver, the webserver may not be the same host as the hostname component of the email identifier, not to mention, what do do you do when you want to switch servers but retain the same identifier?

You could use scoped TXT records like _nip05 to signal your pubkey:

Given test@example.com:

$ORIGIN example.com.
_nip05.test IN TXT “<pubkey>”
_nip05url.text IN TXT "http://<domain>.well-known/nostr.json"

The first record _nip05 would just be a straight reference to the pubkey.

There could also be a reference type for the well-known file URI, but you get the added flexibility that the file doesn't have to reside on the same webserver as example.com.

See: andrerfneves/lightning-address#27 (comment)

And I also wrote this article:

https://bitcoinmagazine.com/technical/simplifying-bitcoin-addresses-dns

This would be great. Or even if we could have a single name as a txt record maybe?

Thank you, this guide was very helpful. I believe I've set this up correctly?

https://davidvkimball.com/.well-known/nostr.json?name=_

I want _@davidvkimball.com to be my NIP-05 key.