From a52d170c8cc5c99cf658d184922dcfe4e8177660 Mon Sep 17 00:00:00 2001 From: Arman The Parman <77603167+ArmanTheParman@users.noreply.github.com> Date: Sun, 16 Jun 2024 19:20:00 +1000 Subject: [PATCH 1/3] Update 01.md This is not a correction but a suggestion... When I first read it, it wasn't clear that metadata is specifically for a user and not inclusive of other things (eg not metadata about a photo). Adding this one extra word here would have helped me understand that immediately. --- 01.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/01.md b/01.md index cdd8b908..d47c2619 100644 --- a/01.md +++ b/01.md @@ -87,7 +87,7 @@ As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key Kinds specify how clients should interpret the meaning of each event and the other fields of each event (e.g. an `"r"` tag may have a meaning in an event of kind 1 and an entirely different meaning in an event of kind 10002). Each NIP may define the meaning of a set of kinds that weren't defined elsewhere. This NIP defines two basic kinds: -- `0`: **metadata**: the `content` is set to a stringified JSON object `{name: , about: , picture: }` describing the user who created the event. [Extra metadata fields](24.md#kind-0) may be set. A relay may delete older events once it gets a new one for the same pubkey. +- `0`: **user's metadata**: the `content` is set to a stringified JSON object `{name: , about: , picture: }` describing the user who created the event. [Extra metadata fields](24.md#kind-0) may be set. A relay may delete older events once it gets a new one for the same pubkey. - `1`: **text note**: the `content` is set to the **plaintext** content of a note (anything the user wants to say). Content that must be parsed, such as Markdown and HTML, should not be used. Clients should also not parse content as those. And also a convention for kind ranges that allow for easier experimentation and flexibility of relay implementation: From 9d8be011c75e8efc7f8a255b9a503571c63f576a Mon Sep 17 00:00:00 2001 From: Arman The Parman <77603167+ArmanTheParman@users.noreply.github.com> Date: Sun, 16 Jun 2024 23:38:14 +1000 Subject: [PATCH 2/3] Update README.md Changed Metadata to User's Metadata, to reduce ambiguity. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 99c42453..067c4367 100644 --- a/README.md +++ b/README.md @@ -90,7 +90,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos ## Event Kinds | kind | description | NIP | | ------------- | -------------------------- | ------------------------ | -| `0` | Metadata | [01](01.md) | +| `0` | User's Metadata | [01](01.md) | | `1` | Short Text Note | [01](01.md) | | `2` | Recommend Relay | 01 (deprecated) | | `3` | Follows | [02](02.md) | From 4f787adcd1cf23ec4d395b26c3a54cd1188fef49 Mon Sep 17 00:00:00 2001 From: Arman The Parman <77603167+ArmanTheParman@users.noreply.github.com> Date: Sun, 16 Jun 2024 23:42:45 +1000 Subject: [PATCH 3/3] Update 05.md Changed metadata to user's metadata --- 05.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/05.md b/05.md index 405078a4..f3a051c7 100644 --- a/05.md +++ b/05.md @@ -6,11 +6,11 @@ Mapping Nostr keys to DNS-based internet identifiers `final` `optional` -On events of kind `0` (`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. +On events of kind `0` (`user's 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 hex formatted public keys. If the public key for the given `` matches the `pubkey` from the `metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier. +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 `` matches the `pubkey` from the `user's metadata` event, the client then concludes that the given pubkey can indeed be referenced by its identifier. ### Example