NIP05: support for locating service using DNS SRV records #29
Conversation
|
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 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 you can see in the ANSWER SECTION that it returns the location of BB06757B.pub.asc.txtBut what do we gain by not reinventing the wheel? Originally posted by @fiatjaf in #7 (comment) |
|
related DNS settings... |
|
I don't see a real problem this nip would solve. It would clearly not be nip 5.
Or please close the PR if you do not need this nip anymore. |
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] 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. |
Sorry, but it does require a webserver to serve the JSON file. And a SSL certificate. For endusers without a personal website it's too much of a burden to add a NIP-05 alias. |
|
@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. |
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.
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. |
A domain without a website is not very useful right now, that's true. Maybe to own your email domain.
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. |
|
@fiatjaf to make sure I understand, are you saying discovery via SRV is already in the spec?
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, @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 |
|
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? |
I'm not proposing to replace the JSON with a TXT record, but to add the DNS as an option. 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. |
|
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. |
As @mikedilger suggested in #146 , the content of the TXT record could be the nprofile string, which contains both the pubkey and the relays. |
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. |
@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:
Here is the only point that makes sense and carries weight:
IMHO NIP-05 has very little value and I don't know why people even care. |
An user owning a domain may not want to use their main domain to serve the NIP05
/.well-knownfor various reasons. They may want to use a subdomain to serve it, e.g.nostr.example.com, but may want their identifier to look like[email protected]and thus not include the subdomain part (i.e.[email protected]). In this case, the best way would be to setup an SRV record on their domain DNS, to indicate the client where to make the request.If the used hostname is indeed
nostr.example.com, the SRV record could look like this:Draft and open to discussion.