mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-11-14 07:49:07 -05:00
6e65b2afb5
Clients currently have no way of querying only root Text Events, which is all they need for a timeline for example. To improve this, the l-tag allows querying root-events or even improve loading of replies on very busy threads by only loading the next level at a time.
75 lines
3.6 KiB
Markdown
75 lines
3.6 KiB
Markdown
NIP-10
|
|
======
|
|
|
|
|
|
On "e", "p" and "l" tags in Text Events (kind 1).
|
|
-------------------------------------------------
|
|
|
|
`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.
|
|
|
|
## Positional "e" tags (DEPRECATED)
|
|
>This scheme is in common use; but should be considered deprecated.
|
|
|
|
`["e", <event-id>, <relay-url>]` as per NIP-01.
|
|
|
|
Where:
|
|
|
|
* `<event-id>` is the id of the event being referenced.
|
|
* `<relay-url>` is the URL of a recommended relay associated with the reference. Many clients treat this field as optional.
|
|
|
|
**The positions of the "e" tags within the event denote specific meanings as follows**:
|
|
|
|
* No "e" tag: <br>
|
|
This event is not a reply to, nor does it refer to, any other event.
|
|
|
|
* One "e" tag: <br>
|
|
`["e", <id>]`: The id of the event to which this event is a reply.
|
|
|
|
* Two "e" tags: `["e", <root-id>]`, `["e", <reply-id>]` <br>
|
|
`<root-id>` is the id of the event at the root of the reply chain. `<reply-id>` is the id of the article to which this event is a reply.
|
|
|
|
* Many "e" tags: `["e", <root-id>]` `["e", <mention-id>]`, ..., `["e", <reply-id>]`<br>
|
|
There may be any number of `<mention-ids>`. These are the ids of events which may, or may not be in the reply chain.
|
|
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>, <pubkey>]`
|
|
|
|
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"`.
|
|
* `<pubkey>` is optional, SHOULD be the pubkey of the author of the referenced event
|
|
|
|
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>`.
|
|
|
|
`<pubkey>` SHOULD be the pubkey of the author of the `e` tagged event, this is used in the outbox model to search for that event from the authors write relays where relay hints did not resolve the event.
|
|
|
|
## 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.
|
|
|
|
## The "l" tag
|
|
|
|
Text events MUST indicate the level in their respective thread. The root event
|
|
MUST use ["l", "0"], replies to an l-0 event MUST use ["l", "1"] etc.
|
|
|
|
As this tag was not defined from day one, clients should not assume 100%
|
|
adoption and use it when querying for root events `…,kinds:[1],"#l":["0"]` or
|
|
immediate replies `…,kinds:[1],"e":[<event-id>],"#l":["3"]` only once broad
|
|
adoption was achieved.
|