kopia lustrzana https://github.com/nostr-protocol/nostr
well-known, JSON-based internet identifier scheme.
rodzic
1aebb3911c
commit
012ebff47d
39
nips/05.md
39
nips/05.md
|
@ -1,35 +1,48 @@
|
|||
NIP-05
|
||||
======
|
||||
|
||||
Mapping usernames to DNS domains
|
||||
--------------------------------
|
||||
Mapping Nostr keys to DNS-based internet identifiers
|
||||
----------------------------------------------------
|
||||
|
||||
`draft` `optional` `author:fiatjaf`
|
||||
|
||||
On events of type `0` (`set_metadata`) one can specify the key `"domain"` with a domain name as the value. Upon seeing that, the client may use it to query a DNS server for a `TXT` record at `_nostrkey.<domain>`. If the result is a hex-encoded key equal to the pubkey of author of that `set_metadata` that means that profile can be identified to the specified domain name.
|
||||
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.
|
||||
|
||||
For example, if a client sees an event like this:
|
||||
Upon seeing that, the client splits the identifier into `<local-part>` and `<domain>` and use these values to make a GET request to `https://<domain>/.well-known/nostr.json?name=<local-part>`.
|
||||
|
||||
The result should be a JSON document object with a key `"names"` that should then be a mapping of names to public keys. If the public key for the given `<name>` matches the `pubkey` from the `set_metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier.
|
||||
|
||||
### Example
|
||||
|
||||
If a client sees an event like this:
|
||||
|
||||
```json
|
||||
{
|
||||
"pubkey": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9",
|
||||
"kind": 0,
|
||||
"content": "{\"name\": \"bob\", \"domain\": \"bob.com\"}"
|
||||
"content": "{\"name\": \"bob\", \"nip05\": \"bob@example.com\"}"
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
The client can proceed to query DNS for the `TXT` record at `_nostrkey.bob.com` and if the value is `b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9` then the client can identify `b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9` with the global name `bob.com` from that point on -- until it sees a new `set_metadata` event from that same pubkey without a `"domain"` key in it or until it checks the DNS again and doesn't see the pubkey there anymore.
|
||||
It will make a GET request to `https://example.com/.well-known/nostr.json?name=bob` and get back a response that will look like
|
||||
|
||||
## User Discovery
|
||||
```json
|
||||
{
|
||||
"names": {
|
||||
"bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
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 "bob.com" there and the client would recognize that it is a domain name, query DNS for the `TXT` record at `_nostrkey.bob.com` and, if a pubkey is found there, use it to search for Nostr events in whatever relays it may choose.
|
||||
That will mean everything is alright.
|
||||
|
||||
## Other notes
|
||||
## Notes
|
||||
|
||||
### Doing DNS queries on browsers
|
||||
### User Discovery implementation suggestion
|
||||
|
||||
If a Nostr client is running on a web browser it won't have access to the low-level sockets needed for the normal DNS protocol, but luckily DNS-over-HTTPS exists now with [widespread usage and support][doh-support] and that can be used for querying. A small instructive example [exists here for inspiration][doh-example].
|
||||
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 "bob@example.com" there and the client would recognize that and do the proper queries to obtain a pubkey and suggest that to the user.
|
||||
|
||||
[doh-support]: https://github.com/curl/curl/wiki/DNS-over-HTTPS
|
||||
[doh-example]: https://github.com/mafintosh/dns-packet/blob/5fbc94b38d1009d7eb21bfeb07563340a2064a3f/examples/doh.js
|
||||
### 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.
|
||||
|
|
Ładowanie…
Reference in New Issue