This must be a new NIP, and remember web clients won't be able to implement it.

I wasn't aware that it isn't possible to resolve DNS records from the browser. That sure complicates things a lot for this change as we cannot ship it if not every client can support it.

Maybe we could change NIP05 to fallback to a precise subdomain nip05.example.com if the GET request to the main domain returns an error? Then it wouldn't be possible to choose the full hostname and port to serve the /.well-known from, but I guess it's an acceptable trade off (as the subdomain nip05. would likely not be already used). That way it would still be possible to use a different domain that the main one, even if it is not possible to choose it.

Thoughts?

I don't like the idea of asking clients to do 2 HTTP calls to resolve each username, but maybe I am just being stupid.

I always thought there would be other key-resolution methods like NIP-05, but for some reason I imagined them having a different syntax so it would be obvious and we wouldn't have to try multiple methods for each.

This is partly what I was trying to get to in issue #7 - NIP-05: gnupg standards compliance

The idea here is/was to implement pka looks ups similar to pgp_dns.md

echo "This is an encrypted message using the public key using the pka-lookups option in gnupg/openpgp..." | \
gpg  --encrypt --armor --auto-key-locate pka -r [email protected] > pka-lookups-message.gpg && \
open pka-lookups-message.gpg && cat pka-lookups-message

TIME=$(date +%s) && echo "This is an encrypted message using the public key using the pka-lookups option in gnupg/openpgp at Time:$TIME" | gpg  --encrypt --armor --auto-key-locate pka -r [email protected] > pka-lookups-message.$TIME.txt.gpg && gpg -d pka-lookups-message.$TIME.txt.gpg && echo

TIME=$(date +%s) && echo "This is an encrypted message using the public key using the pka-lookups option in gnupg/openpgp at Time:$TIME" | gpg  --encrypt --armor --auto-key-locate pka -r [email protected] > pka-lookups-message.$TIME.txt.gpg && gpg -d pka-lookups-message.$TIME.txt.gpg && echo

git at ₿ in ~/pgp.guide on master [?$]
$ dig +answer admin._pka.pgp.guide. TXT

; <<>> DiG 9.10.6 <<>> +answer admin._pka.pgp.guide. TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5652
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;admin._pka.pgp.guide.		IN	TXT

;; ANSWER SECTION:
admin._pka.pgp.guide.	8694	IN	TXT	"v=pka1;fpr=BB06757B.pub.asc.txt;uri=https://pgp.guide/BB06757B.pub.asc.txt"

;; Query time: 288 msec
;; SERVER: 10.1.0.1#53(10.1.0.1)
;; WHEN: Fri Aug 05 23:34:38 EDT 2022
;; MSG SIZE  rcvd: 136


git at ₿ in ~/pgp.guide on master [?$]
$ 

you can see in the ANSWER SECTION that it returns the location of BB06757B.pub.asc.txt

But what do we gain by not reinventing the wheel?

Originally posted by @fiatjaf in #7 (comment)

related DNS settings...

@ 10800 IN ALIAS pgp-guide.github.io.
@ 10800 IN OPENPGPKEY "v=pka1\;fpr=BB06757B\;uri=https://pgp.guide/BB06757B.pub.asc.txt"
@ 10800 IN OPENPGPKEY E616FA7221A1613E5B99206297966C06BB06757B
@ 10800 IN TXT "E616FA7221A1613E5B99206297966C06BB06757B"
...
_imap._tcp 10800 IN SRV 0 0 0   .
_pka 10800 IN TXT "v=pka1;fpr=BB06757B.pub.asc.txt\;uri=https://pgp.guide/BB06757B.pub.asc.txt"
admin._pka 10800 IN TXT "v=pka1;fpr=BB06757B.pub.asc.txt\;uri=https://pgp.guide/BB06757B.pub.asc.txt"
...
key 10800 IN TXT "E616FA7221A1613E5B99206297966C06BB06757B"
...
www 10800 IN CNAME pgp-guide.github.io.

I don't see a real problem this nip would solve. It would clearly not be nip 5.

• OP please suggest an alternative nip number. 34 might be still free.
• Please provide an example implementation.

Or please close the PR if you do not need this nip anymore.

I don't see a real problem this nip would solve. It would clearly not be nip 5.

In contrast this does solve problems for people who may not have freedom to serve at their domain apex.

In fact, the Matrix protocol uses something almost identical for this very same problem: namely, matrix ids can be delegated to subdomain, so that you are identifiable as [email protected], rather than [email protected].

I am against this on the grounds that it introduces a new way of doing a thing that is already being done, thus violating a some principle that probably has a name but I don't know. If people reaaaally want this they should still do it, but I think it would be better to see clear adoption before adding a NIP since otherwise it would be counterproductive.

If you're going to use an email like identifier ([email protected]) to convey the pubkey and other metadata, you have to have an additional level of abstraction above assuming a URI of a well-known file under the hostname component of the identifier.

This is why we have MX records, because without them email would have been largely useless as the internet scaled (taking the same approach would have forced running email and web on the same server).

I used to think SRV records or even a new DNS RR type, until somebody's comment in the lnurl space (same exact issue happening there) made me realize even that is over-complicating it.

Use scoped TXT records with underscores.

given [email protected]

$ORIGIN example.com.

_nip05.me IN TXT "<pubkey>"

;; or maybe
_nostr.me IN TXT "<pubkey>"

;; or even

_nip05.me IN TXT "<wellknown URI/nostr.json>"

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

The difference is that NIP-05 doesn't require a server or any special handling. It is just a static file. It can also be added in two lines directly in your reverse proxy config most likely. For personal websites these two approaches should suffice.

For services and companies the handling is already integrated in your core code that handles user accounts, so you should just reuse your existing server code.

For edge cases in which none of the above applies it is still possible to proxy different paths to different servers.

The difference is that NIP-05 doesn't require a server or any special handling. It is just a static file. It can also be added in two lines directly in your reverse proxy config most likely. For personal websites these two approaches should suffice.

Sorry, but it does require a webserver to serve the JSON file. And a SSL certificate.
It does require to maintain the hosting/hardware, to update regularly the webserver and to renew the certificate.

For endusers without a personal website it's too much of a burden to add a NIP-05 alias.
But it would be possible to register a domain and create the TXT record.
No infrastructure to maintain.

@fiatjaf the point I'm not getting across is that to use an identifier like [email protected] the current implementation is forcing a webserver to exist on example.com and the json file to live there.

It's too restrictive to key an identifier on an email address format and then not provide the ability to abstract away the metadata. This is the reason why email has MX records - because network operators choose to separate their MTAs from their webservers more often than not.

Also - you can still use the well-known filespec URI, but its more flexible (and accessible) if you reference it via some mechanism like a TXT record (I mean even if the clients checked both it could still work for backwards compatibility.

Sorry, but it does require a webserver to serve the JSON file.

Of course, but I was answering in the context of someone who already had a website and for some reason would have to spin up a second specialized server just to handle NIP-05 requests. That was my understanding from the previous criticism.

For endusers without a personal website it's too much of a burden to add a NIP-05 alias.

Who has a domain name but can't host a website? It is very easy, you can use Netlify, Vercel, Firebase Sites, Cloudflare Pages, GitHub Pages, and dozens of other free static site providers. Setting DNS records is just using someone else's server too, so no fundamental difference here.

@markjr the point you're ignoring from me is that this addition is not for free. It has costs. See #146 (comment).

And the benefits, to me, remain ridiculously small, if any.

Also email is not a very successful case of decentralization, so citing that isn't a strong argument. I don't have great experience with email (although I do have some), but all accounts of people that manage email servers of any size and scope that I know of are complaints about how hard is it to keep everything up and all the complexity involved in all the different parts.

Who has a domain name but can't host a website?

A domain without a website is not very useful right now, that's true. Maybe to own your email domain.
But it could be an idea to own your domain for your identity alias.

Setting DNS records is just using someone else's server too, so no fundamental difference here.

1. JSON option needs:

• Domain + records (A + AAAA) + DNS servers (own or external)
• Hosting+ webservers + certificate (own or external)

2. TXT option needs:

• Domain + record (TXT) + DNS servers (own or external)

Clearly option #2 is simpler to manage and requires less trust in external providers (just to the DNS provider).

But it complicates the protocol, as it duplicates the way of adding/checking aliases.
I agree with that.

@fiatjaf to make sure I understand, are you saying discovery via SRV is already in the spec?

Also email is not a very successful case of decentralization, so citing that isn't a strong argument. I don't have great experience with email (although I do have some),

I don't understand this sentiment. What is the point of making identifiers mimic an email address if this is the case? Because my guess is if this format is successful then most people will want to use an actual email address for the NOP05 identifier.

Everybody on the internet has an email address and at least one email address formatted identifier, whether they like email or not. I would call that fairly successful.

(EDIT: my larger point is that the [email protected] format is the perfect identifier structure for decentralized applications, that arose with email, but that email is just a current method for its use. Emerging protocols like this can use this format quite effectively - but they need that level of abstraction to scale.

If this is already in via DNS SRV - while not my preferred method - good enough. That's all I was advocating for in the first place).

@markjr No, SRV records are not supported in the spec. I don't know how to answer your other questions or to justify the design decisions here, I just thought it was simple enough and good.

@oscarrdg Now think about services like minds.com, damus.io, vida.page, nostrplebs.com, nostress.cc, lnmarkets.com, stacker.news and all the other domains that offer NIP-05 addresses for their registered users. How would they be able to do that if they had to create one TXT record for each user?

Also notice the "relays" property in NIP-05. That is a crucial bit for the decentralization aspect of Nostr (if one is adding a Nostr profile from his NIP-05 identifier it is important to know in which relays they are publishing their things). How would that be done with DNS records? More TXT records I guess, but you get my point.

Before I came to nostr I imagined a TXT or SRV record. But I found myself liking the nostr.json file better because I think DNS is less accessible for some people, and takes longer to propagate when changed, than just dropping a file on a website which everybody understands better. Also we've been able to add to that file.

I understand the issue that this forces a webserver onto the machine with the domain's A record, which many will not be happy about. But it's not the end of the world. If it didn't have a webserver yet, setup a tiny program to serve this file. If it did, then use it (the path shouldn't collide with anything). So the problem is really not that great.

The problem would be worse if clients had to check both, and what would happen if they were out of sync?

@oscarrdg Now think about services like minds.com, damus.io, vida.page, nostrplebs.com, nostress.cc, lnmarkets.com, stacker.news and all the other domains that offer NIP-05 addresses for their registered users. How would they be able to do that if they had to create one TXT record for each user?

I'm not proposing to replace the JSON with a TXT record, but to add the DNS as an option.
Obviously, those services you mentioned will continue to use the JSON option, as it is easier to manage for them.

But with the TXT option, a user without a personal website could also own his identity (keypair + alias-nip5) without needing any of those services or setting a webserver.
(But I have already stated that, I don't want to spam too much)
Anyway, thanks for the discussion.

I understand the issue that this forces a webserver onto the machine with the domain's A record, which many will not be happy about. But it's not the end of the world. If it didn't have a webserver yet, setup a tiny program to serve this file. If it did, then use it (the path shouldn't collide with anything). So the problem is really not that great.

If you want mass adoption and if you want to use an email address format identifier, you're not going to get there forcing everybody to have access to the webserver of the hostname component of the email identifier.

The question at the end of the day is do you want mass adoption or not? If yes, then you need another level of abstraction.

Also notice the "relays" property in NIP-05. That is a crucial bit for the decentralization aspect of Nostr (if one is adding a Nostr profile from his NIP-05 identifier it is important to know in which relays they are publishing their things). How would that be done with DNS records?

As @mikedilger suggested in #146 , the content of the TXT record could be the nprofile string, which contains both the pubkey and the relays.

@oscarrdg Now think about services like minds.com, damus.io, vida.page, nostrplebs.com, nostress.cc, lnmarkets.com, stacker.news and all the other domains that offer NIP-05 addresses for their registered users. How would they be able to do that if they had to create one TXT record for each user?

Specifying the desired endpoint to be used for NIP-05, almost like I initially proposed. That would allow us to specify at the DNS level that the request needs to be made to e.g. nostr.lnmarkets.com.

One could want to offer a @example.com NIP-05 domain while hosting the nostr.json on nostr.example.com.

@oscarrdg Now think about services like minds.com, damus.io, vida.page, nostrplebs.com, nostress.cc, lnmarkets.com, stacker.news and all the other domains that offer NIP-05 addresses for their registered users. How would they be able to do that if they had to create one TXT record for each user?

@fiatjaf if users on a system like stacker.news or minds.com are using addresses at those domains for their identifiers, then it's very doable for those platforms to serve up the well-known URIs without needing to publish a DNS TXT record - those are already multi-user systems built on the zone-apex, a platform, if you will. It's easy to just store the nostr.json and serve it when a request comes in.

I'm talking about all the people who want to use this with their own identifiers, under their own domains or emails. It doesn't need to be either/or.

Just define the spec to 1) test for the existence of a well-known URI and if not found, do the DNS lookup (or vice versa).

Email servers do something similar: if they try an MX lookup and don't find one, they attempt to deliver the email to the A record of the hostname component of the email.

This would get you the widest possible coverage.

I have made my points, which you don't seem to appreciate since no one tried to counter them. I don't know what else can I say without repeating myself.

I am definitely a proponent of DNS based records, either TXT or SRV. DNS requires less infrastructure types to be required and also can be secured with DNSSEC without all the problems with SSL certificates and certificate authorities. Any one certificate authority can go rogue and issue bogus certificates and everyone can be compromised. On the contrary, every root DNS server must be compromise in order for DNS security to break down since we can query all root DNS servers at the same time. If one TLD is compromised, only that TLD is compromised. Also, DNS has built in load balancing, redundancy, and delegation. DNS primarily uses UDP which results in substantially lower latency, also DNS caching happens all over the world which further reduces latency. Forcing everyone to use SSL and requiring them to be able to place files on their primary webserver in a specific location seems very limited, similar to my comments in lnurl/luds#93 . Not only does this introduce scalability and configuration limitations, it also introduces new security issues because anyone in your organization that you grant access to your webserver can take over the identity of everyone in the organization. DNS is normally a much more protected resource that isn't necessarily authorized to everyone who helps you create content for your webserver. The webserver shouldn't be the gatekeeper for security. Also, webservers typically have way more security holes possible if you have some custom web applications running on it, whereas DNS has been around for about 40 years and the primary implementation (https://www.isc.org/bind/) has been in development for 37 years as a purpose built and highly secure system. I understand some of your motives described to go with a static file on a webserver, but it just seems like a really bad architecture design. I would suggest to make everyone happy, allow for both options and then people who care about security and scalability can use DNS and people who just want to band aid it together can use the static file on the webserver. It doesn't hurt to have options that serve a broad range of users, but I think the DNS records should be the primary queried by clients since they are the fastest to query and the static file can be a fallback.

DNS security isn't more secure than certificate authorities against the real threat of "the man" who can cancel your domain registration just because they don't like what you say. A more elegant signature chain doesn't make any difference to the real threat.

Here are points against:

• Most nostr clients are written as JavaScript web applications. Browsers don't give them permission, or the interface, to look up DNS records, so I hear.
• Doing it both ways doesn't make everybody happy. It makes developers grumpy as they are now forced to write more code to support the people who only deployed their NIP-05 in DNS.

Here is the only point that makes sense and carries weight:

• Some people without a web server, but in control of a DNS zone, will find doing this with DNS easier because they won't need to setup a web server or indeed have any Internet server at all. It is quite a burden to sign up for a VPS somewhere just for this.

IMHO NIP-05 has very little value and I don't know why people even care.