From f25c7e672c23ca5463fa5c0fcb5e5f424d956862 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Sun, 1 May 2022 07:48:57 -0300 Subject: migrate nips from main nostr repo. --- 05.md | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 05.md (limited to '05.md') diff --git a/05.md b/05.md new file mode 100644 index 0000000..a006ac1 --- /dev/null +++ b/05.md @@ -0,0 +1,52 @@ +NIP-05 +====== + +Mapping Nostr keys to DNS-based internet identifiers +---------------------------------------------------- + +`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 `` part will be restricted to the characters `a-z0-9-_.`, case insensitive. + +Upon seeing that, the client splits the identifier into `` and `` and use these values to make a GET request to `https:///.well-known/nostr.json?name=`. + +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 `` 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\", \"nip05\": \"bob@example.com\"}" + ... +} +``` + +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 + +```json +{ + "names": { + "bob": "b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9" + } +} +``` + +That will mean everything is alright. + +## Notes + +### 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 "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. + +### Showing just the domain as an identifier + +Clients may treat the identifier `_@domain` as the "root" identifier, and choose to display it as just the ``. For example, if Bob owns `bob.com`, he may not want an identifier like `bob@bob.com` as that is redundant. Instead Bob can use the identifier `_@bob.com` and expect Nostr clients to show and treat that as just `bob.com` for all purposes. + +### Reasoning for the `/.well-known/nostr.json?name=` format + +By adding the `` 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. -- cgit v1.2.3