nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-25 09:45:51 -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:
- `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

68
10.md
View File

@ -1,14 +1,48 @@
NIP-10
======
On "e" and "p" tags in Text Events (kind 1).
--------------------------------------------
Text Notes
----------
`draft` `optional`
## 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 defines a `kind:1` as a simple plaintext note.
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)
>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.
>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.