nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-14 15:59:07 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Moves the kind 1 definition to NIP-10

Browse Source
This commit is contained in:
Vitor Pamplona 2024-01-03 14:37:29 -05:00
parent e1b9ffdd09
commit c4daa69498
2 changed files with 39 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
01.md
View File

@ -86,7 +86,6 @@ In case of replaceable events with the same timestamp, the event with the lowest
This NIP defines two kinds: This NIP defines two kinds:
- `kind:0`: **User Metadata**: An event kind to add name and other information to the pubkey. The `content` is set to a stringified JSON object `{name: <user's name, string>, about: <string>, picture: <url, string>}` - `kind:0`: **User Metadata**: An event kind to add name and other information to the pubkey. The `content` is set to a stringified JSON object `{name: <user's name, string>, about: <string>, picture: <url, string>}`
- `kind:1`: **Text Note**: An event kind to transfer **plaintext** content in it's `.content` property. Markup language such as markdown and HTML SHOULD not be used.
## Tags ## Tags

68
10.md
View File

@ -1,14 +1,48 @@
NIP-10 NIP-10
====== ======
Text Notes
On "e" and "p" tags in Text Events (kind 1). ----------
--------------------------------------------
`draft` `optional` `draft` `optional`
## Abstract This NIP defines a `kind:1` as a simple plaintext note.
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, mentions and quotes.
Markup language such as markdown and HTML SHOULD not be used.
## The `p` tag
`["p", <pubkey>, <relay-url>]`
Used in a text event contains a list of pubkeys used to record who is involved in a reply thread.
When replying to a text event E the reply event's `p` tags should contain all of E's `p` tags as well as the `"pubkey"` of the event being replied to.
Example: Given a text event authored by `a1` with `p` tags [`p1`, `p2`, `p3`] then the `p` tags of the reply should be [`a1`, `p1`, `p2`, `p3`]
in no particular order.
## Marked `e` tags
The `e`-tag is defined as follows:
`["e", <event-id>, <relay-url>, <marker>]`
Where:
* `<event-id>` is the id of the event being referenced.
* `<relay-url>` is the URL of a recommended relay associated with the reference. Clients SHOULD add a valid `<relay-URL>` field, but may instead leave it as `""`.
* `<marker>` is optional and if present is one of `"reply"`, `"root"`, or `"mention"`.
Those marked with `"reply"` denote the id of the reply event being responded to. Those marked with `"root"` denote the root id of the reply thread being responded to. For top level replies (those replying directly to the root event), only the `"root"` marker should be used. Those marked with `"mention"` denote a quoted or reposted event id.
A direct reply to the root of a thread should have a single marked `e` tag of type "root".
> This scheme is preferred because it allows events to mention others without confusing them with `<reply-id>` or `<root-id>`.
## 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.
@ -36,27 +70,3 @@ There may be any number of `<mention-ids>`. These are the ids of events which m
They are citing from this event. `root-id` and `reply-id` are as above. They are citing from this event. `root-id` and `reply-id` are as above.
>This scheme is deprecated because it creates ambiguities that are difficult, or impossible to resolve when an event references another but is not a reply. >This scheme is deprecated because it creates ambiguities that are difficult, or impossible to resolve when an event references another but is not a reply.
## Marked "e" tags (PREFERRED)
`["e", <event-id>, <relay-url>, <marker>]`
Where:
* `<event-id>` is the id of the event being referenced.
* `<relay-url>` is the URL of a recommended relay associated with the reference. Clients SHOULD add a valid `<relay-URL>` field, but may instead leave it as `""`.
* `<marker>` is optional and if present is one of `"reply"`, `"root"`, or `"mention"`.
Those marked with `"reply"` denote the id of the reply event being responded to. Those marked with `"root"` denote the root id of the reply thread being responded to. For top level replies (those replying directly to the root event), only the `"root"` marker should be used. Those marked with `"mention"` denote a quoted or reposted event id.
A direct reply to the root of a thread should have a single marked "e" tag of type "root".
>This scheme is preferred because it allows events to mention others without confusing them with `<reply-id>` or `<root-id>`.
## The "p" tag
Used in a text event contains a list of pubkeys used to record who is involved in a reply thread.
When replying to a text event E the reply event's "p" tags should contain all of E's "p" tags as well as the `"pubkey"` of the event being replied to.
Example: Given a text event authored by `a1` with "p" tags [`p1`, `p2`, `p3`] then the "p" tags of the reply should be [`a1`, `p1`, `p2`, `p3`]
in no particular order.