diff options
| author | Vitor Pamplona <vitor@vitorpamplona.com> | 2026-02-03 07:57:31 -0500 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2026-02-03 09:57:31 -0300 |
| commit | 18b948abda8e5a2c414419f824e09f7d379b40e8 (patch) | |
| tree | 9eadf82f3c8451340a5bf73a1a31aa05a11fe5cd | |
| parent | 06593632a83563a2a4172901209ae10beb5decfa (diff) | |
NIP-05: Explicitly requires lowercase for hex keys and names (#2208)
| -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 | ||