mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-22 16:35:52 -05:00
Merge pull request #1309 from ArmanTheParman/patch-2
metadata clarity.md
This commit is contained in:
commit
747f634004
2
01.md
2
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:
|
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: <username>, about: <string>, picture: <url, string>}` 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: <username>, about: <string>, picture: <url, string>}` 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.
|
- `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:
|
And also a convention for kind ranges that allow for easier experimentation and flexibility of relay implementation:
|
||||||
|
|
4
05.md
4
05.md
|
@ -6,11 +6,11 @@ Mapping Nostr keys to DNS-based internet identifiers
|
||||||
|
|
||||||
`final` `optional`
|
`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 `<local-part>` 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 `<local-part>` part will be restricted to the characters `a-z0-9-_.`, case-insensitive.
|
||||||
|
|
||||||
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>`.
|
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>`.
|
||||||
|
|
||||||
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 `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 `<name>` 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
|
### Example
|
||||||
|
|
||||||
|
|
|
@ -90,7 +90,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||||
## Event Kinds
|
## Event Kinds
|
||||||
| kind | description | NIP |
|
| kind | description | NIP |
|
||||||
| ------------- | -------------------------- | ------------------------ |
|
| ------------- | -------------------------- | ------------------------ |
|
||||||
| `0` | Metadata | [01](01.md) |
|
| `0` | User's Metadata | [01](01.md) |
|
||||||
| `1` | Short Text Note | [01](01.md) |
|
| `1` | Short Text Note | [01](01.md) |
|
||||||
| `2` | Recommend Relay | 01 (deprecated) |
|
| `2` | Recommend Relay | 01 (deprecated) |
|
||||||
| `3` | Follows | [02](02.md) |
|
| `3` | Follows | [02](02.md) |
|
||||||
|
|
Loading…
Reference in New Issue
Block a user