NIP-22: Comment
Kind 1 replies were not enough for the rest of Nostr
NIP-22 is the answer to a messy product question: how do people comment on things that are not ordinary text notes? Nostr has articles, files, community posts, calendar events, podcasts, URLs, repositories and app-specific objects. If every object reused kind 1 reply rules differently, clients would spend years guessing thread shape.
The current NIP-22 defines kind 1111 comments. The content is plaintext. The tags do the work. Uppercase tags point at the root scope of the conversation. Lowercase tags point at the direct parent. That lets a client know both what the comment belongs under and what it is replying to.
The standard explicitly separates this from kind 1 note replies. Comments do not replace NIP-10 for ordinary text-note threads. They give non-note objects a cleaner conversation layer.
Root scope above, parent item below
A NIP-22 comment has a root scope and a parent item. For a comment under a long-form article, the root may be an A tag pointing at a kind 30023 address. For a comment under a file, the root may be an E tag pointing at an event ID. For a website or podcast episode, the root can be an I tag pointing at an external identifier.
The uppercase and lowercase split makes nested replies readable. K records the root kind, while k records the parent kind. P points at the root author's pubkey when available, while p points at the parent author. A top-level comment often has matching root and parent references; a reply to a comment keeps the root scope but changes the parent.
NIP-73 supplies values for external identities used in I and i tags. NIP-21 q tags can cite other events in comment content. Mentioned pubkeys can be included with p tags. The result is not elegant at first glance, but it is explicit enough for clients to reconstruct conversations without guessing from content text.
The number was reused; the meaning changed completely
NIP-22's history is unusually instructive because the original file was not the current comment standard. Jeff Thibault added an early NIP-22 in July 2022 about unacceptable event created_at limits. Later commits added relay logic, future-event rejection and more generic wording, with contributions from Leo Wandersleb, Giszmo and others.
In August 2023, that older behavior moved into NIP-01 alongside other base relay behavior. Fiatjaf deleted NIP-22 in December 2023. Then Arthur Franca revived the number in November 2024 with the current Comment standard through PR #1233.
The 2024 and 2025 commits show the new standard becoming practical. Pablo Fernandez added P and p tags. Hodlbod warned against using kind 1111 to reply to kind 1. Fiatjaf clarified I tags. Awiteb and Yoji Shidara fixed example and typo details. The current NIP is draft, but it is clearly being shaped by real non-note discussion needs.
Comments are now a shared dependency for publishing, communities and apps
NIP-22 is already connected to several other standards. NIP-23 says replies to kind 30023 long-form articles use kind 1111 comments. NIP-34 says replies to git issues, patches and pull requests use NIP-22. NIP-72 uses kind 1111 for posts in moderated communities. NIP-B0 uses it for web bookmarking replies. That makes NIP-22 a coordination layer across product areas.
Rust Nostr added NIP-22 helpers in its 0.39.0 release cycle, according to Nobs Bitcoin's release note. Nostrbook lists kind 1111 as Comment. Net::Nostr community documentation shows kind 1111 posts using uppercase and lowercase tags for community scope. Nostr Compass explains the standard as a way to comment on addressable content such as articles, videos and calendar events.
For implementers, the pain point is tag correctness. A malformed comment can look like a reply, but fail to render in the right root discussion. Clients need builders that set root and parent tags correctly, and you need logic that respects the uppercase and lowercase distinction.
Structured comments can still become messy threads
The first risk is client drift. If one client writes uppercase root tags incorrectly and another client reads only lowercase parent tags, the discussion breaks into fragments. Users experience that as missing comments, duplicated top-level replies or replies under the wrong object.
The second risk is moderation. NIP-22 makes comments portable, which also makes abuse portable. Communities, articles and file pages need relay policy, moderation events, reporting and filtering beside the comment standard itself. A comment format is not a moderation system.
Read NIP-22 in the wild
NIP-22 gives comments a clearer object than ordinary replies. A comment can point at a Nostr event or an external object, which lets articles, videos, code, products and web pages collect discussion without living inside one platform.
The hard part is moderation and context. A portable comment layer can enrich the web, but it can also bring spam, abuse and mismatched audiences. Clients need source context, target identity and filtering choices.
What changes when you actually use it
For you, NIP-22: Comment 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 1111, kind 1, draft, kind:1111, .content, E 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-22: Comment is compatibility discipline. Implement kind 1111, kind 1, draft, kind:1111, .content, E 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 Examples. Inspect kind 1111, kind 1, draft, kind:1111, .content, E, A, e because these are the pieces most likely to surface as product behavior. Read it beside NIP-73, NIP-21, NIP-10, NIP-94 before treating it as isolated.
NIP-22: Comment 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-22: Comment is often indirect. Nobody complains about kind 1111, kind 1, draft, kind:1111, .content, E; 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-22: Comment 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 1111, kind 1, draft, kind:1111, .content, E 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-22: Comment 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-73, NIP-21, NIP-10, NIP-94 to see where the base contract ends and the product-specific promise begins.
Language that keeps the feature honest
Good product copy for NIP-22: Comment 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-22: Comment 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-22: Comment with the visible product symptom, then trace it back to kind 1111, kind 1, draft, kind:1111, .content, E. 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: nips.nostr.com NIP-22 mirror, PR #1233: NIP-22 Comment, NIP-23 Long-form Content, NIP-72 Moderated Communities. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-22 source is the anchor for exact wording, and NIP-22 commit history shows how that wording moved over time. The strongest secondary clues here are nips.nostr.com NIP-22 mirror, PR #1233: NIP-22 Comment, NIP-23 Long-form Content. 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-22: Comment: first the human promise, then kind 1111, kind 1, draft, kind:1111, .content, E, then the implementation record, then the real-world failure case. That order keeps NIP-22 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Can two independent clients read the same
kind 1111,kind 1,draft,kind:1111without 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-73, NIP-21, NIP-10, NIP-94, changes the behavior once the base event leaves the happy path?
What to verify before you rely on it
- Find
kind 1111,kind 1,draft,kind:1111,.contentin the official file and check where the UI exposes the same concept. - Read NIP-73, NIP-21, NIP-10, NIP-94 as context before treating NIP-22 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-22: Comment in that order: Official NIP-22 source for the current wording; NIP-22 commit history for the change record; nips.nostr.com NIP-22 mirror, PR #1233: NIP-22 Comment, NIP-23 Long-form Content 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.
