diff options
| -rw-r--r-- | 05.md | 10 |
1 files changed, 9 insertions, 1 deletions
| @@ -6,7 +6,7 @@ Mapping Nostr keys to DNS-based internet identifiers | |||
| 6 | 6 | ||
| 7 | `final` `optional` `author:fiatjaf` | 7 | `final` `optional` `author:fiatjaf` |
| 8 | 8 | ||
| 9 | 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. | 9 | On events of kind `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. |
| 10 | 10 | ||
| 11 | 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>`. | 11 | 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>`. |
| 12 | 12 | ||
| @@ -37,8 +37,16 @@ It will make a GET request to `https://example.com/.well-known/nostr.json?name=b | |||
| 37 | 37 | ||
| 38 | That will mean everything is alright. | 38 | That will mean everything is alright. |
| 39 | 39 | ||
| 40 | ## Finding users from their NIP-05 identifier | ||
| 41 | |||
| 42 | A client may implement support for finding users' public keys from _internet identifiers_, the flow is the same as above, but reversed: first the client fetches the _well-known_ URL and from there it gets the public key of the user, then it tries to fetch the kind `0` event for that user and check if it has a matching `"nip05"`. | ||
| 43 | |||
| 40 | ## Notes | 44 | ## Notes |
| 41 | 45 | ||
| 46 | ### Clients must always follow public keys, not NIP-05 addresses | ||
| 47 | |||
| 48 | For example, if after finding that `bob@bob.com` has the public key `abc...def`, the user clicks a button to follow that profile, the client must keep a primary reference to `abc...def`, not `bob@bob.com`. If, for any reason, the address `https://bob.com/.well-known/nostr.json?name=bob` starts returning the public key `1d2...e3f` at any time in the future, the client must not replace `abc...def` in his list of followed profiles for the user (but it should stop displaying "bob@bob.com" for that user, as that will have become an invalid `"nip05"` property). | ||
| 49 | |||
| 42 | ### User Discovery implementation suggestion | 50 | ### User Discovery implementation suggestion |
| 43 | 51 | ||
| 44 | 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. | 52 | 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. |