NIP-05: Mapping usernames to DNS domains #35
Conversation
|
Thinking about this I think it's bad, DNS is not the most straightforward thing, and this doesn't work for multiple accounts per domain, which would be nice to support, like [email protected]. I'm now inclined to use the |
|
Ok, updated the proposal. I think it's much better now, more flexible and easier to implement. |
|
|
||
| ### User Discovery implementation suggestion | ||
|
|
||
| A client can also use this to allow users to search other profiles. If a client has a search box or something like that, a user may be able to type "[email protected]" there and the client would recognize that and do the proper queries to obtain a pubkey and suggest that to the user. |
There was a problem hiding this comment.
What about searching for all users on particular domain? Should searching for just example.com be supported usecase?
There was a problem hiding this comment.
Good idea! I think it should. If the domain wants to provide a list of all users (instead of dynamically generating that page for each single requested user) that could be indeed a nice feature for clients.
|
|
||
| ### Reasoning for the `/.well-known/nostr.json?name=<local-part>` format | ||
|
|
||
| By adding the `<local-part>` as a query string instead of as part of the path the protocol can support both dynamic servers that can generate JSON on-demand and static servers with a JSON file in it that may contain multiple names. |
There was a problem hiding this comment.
So the query part with the <local-part> is optional? Can client just request /.well-known/nostr.json and do the search localy?
And on the relay part the support for query string is also optional? Event if the client adds the query, server still might return the whole JSON with all users because it might be just static server serving actual JSON file?
If that is the case I think it should be described in the specification.
There was a problem hiding this comment.
For the client it is not optional, as a server may require the <local-part> to be able to dynamically fetch a user from its database or something like that. But the client should be able to try and get a list of all users for search purposes, always aware that the request could fail or return an empty list.
On the server part (this doesn't have to be a relay, it's just a server providing names) it can choose to ignore the query -- and if it's just a static file the query will be automatically ignored and the entire file will be returned anyway.
The spec is not super specific right now, but we can improve on that.
| } | ||
| ``` | ||
|
|
||
| That will mean everything is alright. |
There was a problem hiding this comment.
What does that mean? How should client treat failure?
|
|
||
| `draft` `optional` `author:fiatjaf` | ||
|
|
||
| On events of type `0` (`set_metadata`) one can specify the key `"nip05"` with an [internet identifier](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (an email-like address) as the value. Although there is a link to a very liberal "internet identifier" specification above, NIP-05 assumes the `<local-part>` part will be restricted to the characters `a-z0-9-_.`, case insensitive. |
There was a problem hiding this comment.
Should client also do validation when creating new set_metadata event?
And what about receiving relay? Should it validate reveived events with nip05 key?
There was a problem hiding this comment.
You mean clients should validate if the specified nip05 field really translates into that same pubkey when the server is queried?
Yes, I guess they could do that, but I personally don't think it's a good idea.
This is a proposal for tying Nostr keys to DNS domains or subdomains using DNS.