Moves kind1 definition from NIP01 to NIP10 to avoid confusing that it is mandatory to work with Kind 1s.

This commit is contained in:
Vitor Pamplona 2024-02-23 08:15:01 -05:00
parent 4313fbf7a5
commit 7c9e183536
3 changed files with 12 additions and 6 deletions

3
01.md
View File

@ -85,10 +85,9 @@ As a convention, all single-letter (only english alphabet letters: a-z, A-Z) key
### Kinds ### 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: 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 one basic kind:
- `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. A relay may delete older events once it gets a new one for the same pubkey. - `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. 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: And also a convention for kind ranges that allow for easier experimentation and flexibility of relay implementation:

13
10.md
View File

@ -1,15 +1,22 @@
NIP-10 NIP-10
====== ======
Text Notes
On "e" and "p" tags in Text Events (kind 1). ----------
--------------------------------------------
`draft` `optional` `draft` `optional`
This NIP defines `kind:1` as a simple plaintext note.
## Abstract ## Abstract
This NIP describes how to use "e" and "p" tags in text events, especially those that are replies to other text events. It helps clients thread the replies into a tree rooted at the original event. This NIP describes how to use "e" and "p" tags in text events, especially those that are replies to other text events. It helps clients thread the replies into a tree rooted at the original event.
The `.content` property contains a text.
`e` and `p` tags can be used to define note threads, replies and mentions.
Markup languages such as markdown and HTML SHOULD NOT be used.
## Positional "e" tags (DEPRECATED) ## Positional "e" tags (DEPRECATED)
>This scheme is in common use; but should be considered deprecated. >This scheme is in common use; but should be considered deprecated.

View File

@ -31,7 +31,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-07: `window.nostr` capability for web browsers](07.md) - [NIP-07: `window.nostr` capability for web browsers](07.md)
- [NIP-08: Handling Mentions](08.md) --- **unrecommended**: deprecated in favor of [NIP-27](27.md) - [NIP-08: Handling Mentions](08.md) --- **unrecommended**: deprecated in favor of [NIP-27](27.md)
- [NIP-09: Event Deletion](09.md) - [NIP-09: Event Deletion](09.md)
- [NIP-10: Conventions for clients' use of `e` and `p` tags in text events](10.md) - [NIP-10: Text Notes and Threads](10.md)
- [NIP-11: Relay Information Document](11.md) - [NIP-11: Relay Information Document](11.md)
- [NIP-13: Proof of Work](13.md) - [NIP-13: Proof of Work](13.md)
- [NIP-14: Subject tag in text events](14.md) - [NIP-14: Subject tag in text events](14.md)