diff options
| author | Alex Gleason <alex@alexgleason.me> | 2026-04-10 13:31:37 -0500 |
|---|---|---|
| committer | Alex Gleason <alex@alexgleason.me> | 2026-04-10 13:31:37 -0500 |
| commit | 5e1e24766910fc07cb61a049aed2623987458ec2 (patch) | |
| tree | b7588f61fddf9374268d5cd6f4e3f2655d7c840a /05.md | |
| parent | b8782df594b4e7e8f088869134908eed58be6078 (diff) | |
| parent | 3465f540e3eaedccb5309711b502f0febf56b52f (diff) | |
Merge nip44-big-payloads into bigger-nip44bigger-nip44
Diffstat (limited to '05.md')
| -rw-r--r-- | 05.md | 6 |
1 files changed, 3 insertions, 3 deletions
| @@ -6,11 +6,11 @@ Mapping Nostr keys to DNS-based internet identifiers | |||
| 6 | 6 | ||
| 7 | `final` `optional` | 7 | `final` `optional` |
| 8 | 8 | ||
| 9 | On events of kind `0` (`user 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` (`user 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, the `<local-part>` part MUST only use characters `a-z0-9-_.`. |
| 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 | ||
| 13 | The result should be a JSON document object with a key `"names"` that should then be a mapping of names to hex formatted public keys. If the public key for the given `<name>` matches the `pubkey` from the `user metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier. | 13 | The result should be a JSON document object with a key `"names"` that should then be a mapping of names to hex formatted public keys, in lowercase. If the public key for the given `<name>` matches the `pubkey` from the `user metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier. |
| 14 | 14 | ||
| 15 | ### Example | 15 | ### Example |
| 16 | 16 | ||
| @@ -73,7 +73,7 @@ For example, if after finding that `bob@bob.com` has the public key `abc...def`, | |||
| 73 | 73 | ||
| 74 | ### Public keys must be in hex format | 74 | ### Public keys must be in hex format |
| 75 | 75 | ||
| 76 | Keys must be returned in hex format. Keys in NIP-19 `npub` format are only meant to be used for display in client UIs, not in this NIP. | 76 | Keys must be returned in hex format, in lowercase. Keys in NIP-19 `npub` format are only meant to be used for display in client UIs, not in this NIP. |
| 77 | 77 | ||
| 78 | ### Showing just the domain as an identifier | 78 | ### Showing just the domain as an identifier |
| 79 | 79 | ||