diff --git a/10.md b/10.md index 94db4fa..c1d5068 100644 --- a/10.md +++ b/10.md @@ -10,33 +10,6 @@ On "e" and "p" tags in Text Events (kind 1) ## 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", , ]` as per NIP-01. - -Where: - - * `` is the id of the event being referenced. - * `` 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:
- This event is not a reply to, nor does it refer to, any other event. - - * One "e" tag:
- `["e", ]`: The id of the event to which this event is a reply. - - * Two "e" tags: `["e", ]`, `["e", ]`
- `` is the id of the event at the root of the reply chain. `` is the id of the article to which this event is a reply. - - * Many "e" tags: `["e", ]` `["e", ]`, ..., `["e", ]`
-There may be any number of ``. 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", , , , ]` @@ -62,3 +35,33 @@ When replying to a text event E the reply event's "p" tags should contain all of 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. + +## Deprecated Positional "e" tags + +This scheme is not in common use anymore and is here just to keep backward compatibility with older events on the network. + +Positional `e` tags are deprecated because they create ambiguities that are difficult, or impossible to resolve when an event references another but is not a reply. + +They use simple `e` tags without any marker. + +`["e", , ]` as per NIP-01. + +Where: + + * `` is the id of the event being referenced. + * `` 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:
+ This event is not a reply to, nor does it refer to, any other event. + + * One "e" tag:
+ `["e", ]`: The id of the event to which this event is a reply. + + * Two "e" tags: `["e", ]`, `["e", ]`
+ `` is the id of the event at the root of the reply chain. `` is the id of the article to which this event is a reply. + + * Many "e" tags: `["e", ]` `["e", ]`, ..., `["e", ]`
+There may be any number of ``. 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. \ No newline at end of file