{"id":"bb1fe383b927645f412a31da7e2401828f99a5a26933af7bf5d49a10b88eaf13","pubkey":"2b39b4ffe62933df970e19366c22c1e092f953f83fcfed754e0f04d5a3b459f9","created_at":1738958399,"kind":30817,"tags":[["d","nip-10"],["title","NIP-10: Text Notes and Threads"],["summary","How kind 1 notes thread: the markers on e tags that name the root and the parent, and the q tags that cite another event."],["s","draft"],["t","nostr"],["t","nip"],["k","1","Short Text Note"],["alt","A specification: NIP-10: Text Notes and Threads"],["client","openspecs-import"],["published_at","1651683651"],["proxy","https://github.com/nostr-protocol/nips/blob/656cecc7c0a815b6a2b218d3b5d6f078b3f4dbab/10.md","web"],["x","655501f90e70e838561f3b63134f1b0a9ddcbf6e4de05fbbacc0990bcbe5a5d8"]],"content":"NIP-10\n======\n\nText Notes and Threads\n----------------------\n\n`draft` `optional`\n\nThis NIP defines `kind:1` as a simple plaintext note.\n\n## Abstract\n\nThe `.content` property contains some human-readable text. \n\n`e` tags can be used to define note thread roots and replies. They SHOULD be sorted by the reply stack from root to the direct parent.\n\n`q` tags MAY be used when citing events in the `.content` with [NIP-21](nostr:naddr1qvzqqqrcvypzq2eeknl7v2fnm7tsuxfkds3vrcyjl9fls070a465urcy6k3mgk0eqqrxu6ts95erzkumy4n).\n\n```json\n[\"q\", \"<event-id> or <event-address>\", \"<relay-url>\", \"<pubkey-if-a-regular-event>\"]\n```\n\nAuthors of the `e` and `q` tags SHOULD be added as `p` tags to notify of a new reply or quote.\n\nMarkup languages such as markdown and HTML SHOULD NOT be used. \n\n## Marked \"e\" tags (PREFERRED)\n\nKind 1 events with `e` tags are replies to other kind 1 events. Kind 1 replies MUST NOT be used to reply to other kinds, use [NIP-22](nostr:naddr1qvzqqqrcvypzq2eeknl7v2fnm7tsuxfkds3vrcyjl9fls070a465urcy6k3mgk0eqqrxu6ts95ery2ncpfy) instead. \n\n`[\"e\", <event-id>, <relay-url>, <marker>, <pubkey>]`\n\nWhere:\n\n * `<event-id>` is the id of the event being referenced.\n * `<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 `\"\"`.\n * `<marker>` is optional and if present is one of `\"reply\"`, `\"root\"`.\n * `<pubkey>` is optional, SHOULD be the pubkey of the author of the referenced event\n\nThose 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. \n\nA direct reply to the root of a thread should have a single marked \"e\" tag of type \"root\".\n\n>This scheme is preferred because it allows events to mention others without confusing them with `<reply-id>` or `<root-id>`.\n\n`<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.\n\n## The \"p\" tag\nUsed in a text event contains a list of pubkeys used to record who is involved in a reply thread.\n\nWhen 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.\n\nExample:  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`]\nin no particular order.\n\n## Deprecated Positional \"e\" tags\n\nThis scheme is not in common use anymore and is here just to keep backward compatibility with older events on the network. \n\nPositional `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.\n\nThey use simple `e` tags without any marker. \n\n`[\"e\", <event-id>, <relay-url>]` as per NIP-01.\n\nWhere:\n\n * `<event-id>` is the id of the event being referenced.\n * `<relay-url>` is the URL of a recommended relay associated with the reference.  Many clients treat this field as optional.\n\n**The positions of the \"e\" tags within the event denote specific meanings as follows**:\n\n * No \"e\" tag: <br>\n This event is not a reply to, nor does it refer to, any other event.\n\n * One \"e\" tag: <br>\n `[\"e\", <id>]`: The id of the event to which this event is a reply.\n\n * Two \"e\" tags:  `[\"e\", <root-id>]`, `[\"e\", <reply-id>]` <br>\n `<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.\n\n * Many \"e\" tags: `[\"e\", <root-id>]` `[\"e\", <mention-id>]`, ..., `[\"e\", <reply-id>]`<br>\nThere may be any number of `<mention-ids>`.  These are the ids of events which may, or may not be in the reply chain.\nThey are citing from this event.  `root-id` and `reply-id` are as above.","sig":"336bb449bc2715d1e74cf05dde4c0047dd5a7f2fec2ed7286f36a0c77811d99e94923022c220b3b8db4b8e2b82e7c87519192866e5a45d6766f99e07dd542656"}