NIP-10: Text Notes and Threads
Most people meet Nostr through this event shape
NIP-10 is where the familiar social surface of Nostr becomes a standard. A short note, a reply, a quote, a thread root, a parent event and a set of notified people all look ordinary in the client. Underneath, those behaviors depend on tags inside a signed event.
The standard defines kind 1 as a short text note and explains how text-note conversations use e, p and q tags. It moved much of this social-note detail out of the base protocol so NIP-01 could stay focused on core event mechanics.
That separation matters. NIP-01 tells you what an event is. NIP-10 tells you how the main public conversation object behaves. A client can technically move events without understanding threads, but a social app that mishandles NIP-10 will feel broken very quickly.
Plain text, roots, replies and citations
A kind 1 note has human-readable plaintext in content. The official text explicitly avoids HTML and Markdown as protocol-level formatting. This does not stop clients from rendering links or richer previews, but the event itself remains plain text.
Threading uses e tags. The preferred model uses markers: root for the thread root and reply for the direct parent. The tags can include relay hints and, in modern form, the author pubkey of the referenced event. The old positional model remains documented for backward compatibility, but marked tags are the readable path.
Quotes use q tags when an event is cited in the content through a NIP-21 reference. Authors of referenced e and q tags are added as p tags so clients can notify them. That one rule turns a quote or reply from a visual link into a social signal.
Threading kept changing because products kept finding ambiguous edges
The file history shows a long clean-up path. Early reply conventions were part of the inherited Nostr grammar. In February 2023, relay-hint language changed as clients learned how hard discovery was. In 2023 and 2024, the old mention marker and legacy positional conventions were pushed downward as marked roots and replies became the safer reading.
In April 2024, Kieran Harkin added pubkeys on e tags to help with the outbox model when relay hints are not enough. In January 2025, kind 1 moved into NIP-10 from NIP-01. In February 2025, Vitor Pamplona removed the old mention marker in favor of q tags, and the spec drew a stronger line: kind 1 replies are for kind 1; comments on other event kinds belong in NIP-22.
Recent discussion keeps the pressure on that boundary. Issue #2288 asks whether kind 1 replies themselves need deprecation in favor of a more scoped comment model. Whether or not that happens, it shows why NIP-10 is not a static glossary page. It is the contested center of public Nostr conversation.
The visible timeline depends on small tag choices
A client implementing NIP-10 has to do more than show text. It has to resolve the thread root, load the direct parent, distinguish quotes from replies, avoid treating legacy positional tags as stronger than marked tags, add notification context and keep relay hints useful without overtrusting them.
The hardest bugs are social rather than cryptographic. A reply can appear under the wrong root. A quote can notify the wrong person. A kind 1 note can try to behave like a comment on an article or live event, even though NIP-22 now gives that job a separate kind. The user sees those bugs as messy conversation, not as malformed tags.
Nostrbook's kind 1 page and the NIP-22 mirrors are helpful because they show how this grammar becomes product behavior: timeline posts, reply chains, quote posts and comments are adjacent but not identical. A mature client needs that distinction.
Conversation breaks when old and new conventions blur
The major risk is ambiguous threading. Nostr has old positional tags, marked tags, quotes, replies, reposts and comments. When a client collapses all of that into one mental bucket, users see wrong parents, missing roots or noisy notifications.
The second risk is product overreach. Kind 1 is the default public note, not every possible comment surface. The move toward NIP-22 for scoped comments is a sign that ordinary social notes and comments on other objects need different structure.
Read NIP-10 in the wild
NIP-10 explains why replies and threads can be reconstructed instead of being trapped in one app's comment table. It gives clients a way to mark roots, replies and mentions so conversation context survives across relays and interfaces.
The failure mode is familiar: a reply appears as a standalone post, a thread forks into duplicates, or a client loads a conversation with the middle missing. This NIP matters because conversation is not only content; it is context.
What changes when you actually use it
For you, NIP-10: Text Notes and Threads is felt when an app either behaves predictably or suddenly loses context. The visible symptom may be a missing reply, a broken link, a strange reaction count, an empty result or a relay error that looks like the whole network failed. The official terms kind 1, draft, kind:1, .content, e, p are where that visible behavior begins, so the source is not background material; it is the place where the product promise gets its limits.
What changes for builders and operators
For builders, NIP-10: Text Notes and Threads is compatibility discipline. Implement kind 1, draft, kind:1, .content, e, p against more than one relay and more than one library, then test malformed, missing and duplicated data. Core standards fail most painfully when the happy path looks fine and the second client exposes the shortcut.
What the official file makes concrete
The official file is organized around Abstract, Marked "e" tags (PREFERRED), The "p" tag, Deprecated Positional "e" tags. Inspect kind 1, draft, kind:1, .content, e, p, ["e", <event-id>, <relay-url>, <marker>, <pubkey>], <event-id> because these are the pieces most likely to surface as product behavior. Read it beside NIP-21, NIP-22, NIP-01 before treating it as isolated.
NIP-10: Text Notes and Threads is a shared contract between independent software. The smallest field can become user-visible when two clients disagree about it.
Where it breaks
The failure mode in NIP-10: Text Notes and Threads is often indirect. Nobody complains about kind 1, draft, kind:1, .content, e, p; they complain that the feed is wrong, the reply vanished or the relay behaved strangely. Use the official file to diagnose the hidden cause instead of patching only the visual symptom.
Where this appears outside the markdown
In the ecosystem, NIP-10: Text Notes and Threads is not something most people choose directly. It is the invisible grammar behind clients, relays, crawlers, search tools and archives. When a product team treats kind 1, draft, kind:1, .content, e, p as implementation detail only, the mistake eventually reaches the surface as missing history, bad threading or state that cannot be reconstructed after a client switch.
The nearby-standard trap
The nearby-standard trap in NIP-10: Text Notes and Threads is assuming the base layer solves the higher-level feature. This NIP may define the common grammar, but publishing, wallets, moderation, media or groups still need their own constraints. Read NIP-21, NIP-22, NIP-01 to see where the base contract ends and the product-specific promise begins.
Language that keeps the feature honest
Good product copy for NIP-10: Text Notes and Threads does not say "the protocol handles it" and move on. It explains the visible consequence: what was sent, what was accepted, what was rejected, what is still loading and what another relay or client may show differently.
What this page does not promise
NIP-10: Text Notes and Threads does not promise a finished social product. It gives software a shared grammar. Feed design, moderation, ranking, notifications, storage duration and recovery remain separate product decisions. That distinction matters because a client can be technically compatible and still give you a weak experience if it hides relay errors, drops context or treats optional fields as if every app understood them.
Read it as a field test
Start NIP-10: Text Notes and Threads with the visible product symptom, then trace it back to kind 1, draft, kind:1, .content, e, p. That order keeps the article grounded: you see why the field exists, which relay or client behavior depends on it, and where adjacent standards change the story. A core NIP is strong only when it explains both the normal path and the awkward edge case.
Where the standard earns trust
The source links give you places to test the interpretation in public: Issue #1101: NIP-10 / NIP-18 conflict, Issue #2288: deprecate kind 1 replies, NIP-21 nostr: URI scheme, NIP-22 Comment. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-10 source is the anchor for exact wording, and NIP-10 commit history shows how that wording moved over time. The strongest secondary clues here are Issue #1101: NIP-10 / NIP-18 conflict, Issue #2288: deprecate kind 1 replies, NIP-21 nostr: URI scheme. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-10: Text Notes and Threads: first the human promise, then kind 1, draft, kind:1, .content, e, p, then the implementation record, then the real-world failure case. That order keeps NIP-10 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Can two independent clients read the same
kind 1,draft,kind:1,.contentwithout a hidden compatibility rule? - Does the UI explain relay rejection, missing context or state replacement without blaming the whole network?
- Which adjacent standard, especially NIP-21, NIP-22, NIP-01, changes the behavior once the base event leaves the happy path?
What to verify before you rely on it
- Find
kind 1,draft,kind:1,.content,ein the official file and check where the UI exposes the same concept. - Read NIP-21, NIP-22, NIP-01 as context before treating NIP-10 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-10: Text Notes and Threads in that order: Official NIP-10 source for the current wording; NIP-10 commit history for the change record; Issue #1101: NIP-10 / NIP-18 conflict, Issue #2288: deprecate kind 1 replies, NIP-21 nostr: URI scheme for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
