NIP-7D: Forum Threads
Forums need a root topic, not only social replies
A forum thread is different from a note that happens to get replies. It needs a topic, a title and a reply model that keeps discussion attached to the root. NIP-7D gives that shape with kind 11 threads.
Replies use NIP-22 kind 1111 comments. The NIP recommends replying to the root kind 11 event rather than building arbitrary nested reply hierarchies. That keeps forum clients readable.
This is deliberately small. It does not define a whole community system, moderation model or voting system. It defines the thread object.
Kind 11 roots and kind 1111 comments
A thread is kind 11. It needs to include a title tag and can carry opening content. A reply is a NIP-22 comment, kind 1111, pointing back to the root thread with uppercase root tags.
The example uses K and E tags to identify the root kind and event. The NIP's simplicity is the main feature: clients can build a forum list, open a thread and display comments without mapping the entire social graph.
Because it relies on NIP-22, NIP-7D belongs near comments, forums and community pages.
Forum threads were broken out from group work
hodlbod broke chat and threads out from NIP-29 in November 2024. In April 2025, fiatjaf changed subject to title. In May 2026, sanity cleanup touched the file.
That history explains why NIP-7D feels small. It is not trying to carry all group behavior; it is the thread primitive separated from the broader group protocol.
For people, the important point is that forum threads are a basic discussion shape that can be combined with other moderation or community standards.
The UI needs to keep replies attached to the root
A forum client needs to show thread title, root content, author, reply count and kind 1111 comments. It needs to avoid turning the view into an endlessly nested social reply tree unless it has a clear forum reason.
NIP-7D can sit beside NIP-29 groups, NIP-72 legacy communities or standalone forum clients. The same thread object can be indexed and displayed by several contexts.
A clean implementation lets a user discover threads by title, open one discussion and reply without learning event-kind mechanics.
Small thread objects still need moderation context
A thread can be spammed, brigaded or duplicated. NIP-7D does not solve moderation; it gives the discussion object that other systems can moderate.
If clients disagree on reply scoping, a forum can fragment. Careful products follow NIP-22 root tagging so the thread does not split into several incompatible rooms.
Read NIP-7D in the wild
NIP-7D gives forum threads a cleaner shape. A forum is not a timeline and not a chat room; it needs topics, replies, sorting, moderation context and enough persistence for people to return later.
The danger is mixing mental models. If clients render forum threads like ordinary notes, context disappears. If they render them like private groups, they may overpromise privacy. Keep the room type visible.
What changes when you actually use it
For you, NIP-7D: Forum Threads is felt when a specialized experience still remains portable. Games, forums, handlers, static sites and local transports become useful only when another client can understand the same object. The source terms kind 11, kind 1111, draft, title are the difference between an open feature and a private app convention.
What changes for builders and operators
For builders, NIP-7D: Forum Threads needs cross-client proof. Create an object in one product, open it in another, then test what survives without special server knowledge. That is where an app-specific idea becomes a real Nostr surface.
What the official file makes concrete
Inspect kind 11, kind 1111, draft, title because these are the pieces most likely to surface as product behavior. Read it beside NIP-22 before treating it as isolated.
NIP-7D: Forum Threads earns trust when a second client can understand the same object without a private handshake.
Where it breaks
The failure mode in NIP-7D: Forum Threads is private interoperability. The event exists on Nostr, but only the original app knows how to use it. Test a second interface and a second relay before calling the feature portable.
Where this appears outside the markdown
In the ecosystem, NIP-7D: Forum Threads is where Nostr stops being only a feed and becomes a surface for specialized products: forums, games, static sites, handlers, local transport or application state. The standard matters only when another client can open the same object without calling the first app for private instructions.
The nearby-standard trap
The nearby-standard trap in NIP-7D: Forum Threads is mistaking novelty for interoperability. A clever app-specific event is not a standard until another client can use it. Read NIP-22 to see whether the feature has a path out of its first product.
Language that keeps the feature honest
Good product copy for NIP-7D: Forum Threads names portability. It tells you whether another client can open the object, whether a relay or app-specific convention is required, and what might fail when you leave the original product.
What this page does not promise
NIP-7D: Forum Threads does not make a niche feature portable just because it uses Nostr events. Portability begins when another client can parse the object, recover the context and show a useful experience without a private API. Read NIP-22 and look for second-client evidence before treating the format as settled.
Read it as a field test
Start NIP-7D: Forum Threads with interoperability. If kind 11, kind 1111, draft, title cannot travel into another useful interface, the feature is still mostly an app convention. Read NIP-22 and look for public examples before assuming a specialized NIP has become a stable product surface.
Where the standard earns trust
The source links give you places to test the interpretation in public: NIP-22 Comments, NIP-29 Relay-based Groups, Nostrbook groups comparison. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-7D source is the anchor for exact wording, and NIP-7D commit history shows how that wording moved over time. The strongest secondary clues here are NIP-22 Comments, NIP-29 Relay-based Groups, Nostrbook groups comparison. 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-7D: Forum Threads: first the human promise, then kind 11, kind 1111, draft, title, then the implementation record, then the real-world failure case. That order keeps NIP-7D useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Can a second app open the object and make it useful, or does the first product still carry the real meaning?
- Which part is standardized in
kind 11,kind 1111,draft,title, and which part remains a convention, server policy or UI choice? - What happens when the app, relay, local transport or handler that created the object is gone?
What to verify before you rely on it
- Find
kind 11,kind 1111,draft,titlein the official file and check where the UI exposes the same concept. - Read NIP-22 as context before treating NIP-7D 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-7D: Forum Threads in that order: Official NIP-7D source for the current wording; NIP-7D commit history for the change record; NIP-22 Comments, NIP-29 Relay-based Groups, Nostrbook groups comparison 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.
