NIP-72: Moderated Communities (Reddit Style)
Nostr wanted public communities with moderator approval
NIP-72 tried to model Reddit-style communities on Nostr. A community definition names the community and moderators. Users post by tagging the community. Moderators issue approval events so clients can decide what belongs in the community view.
That is a real product need. Nostr without communities can feel like one giant feed. People want topic spaces, moderation and community identity without giving one platform the whole database.
But the current official file begins with a warning: NIP-72 is unrecommended and people needs to try NIP-29 instead. A good article must say that plainly.
Community definitions, posts and approvals
Community definitions use kind 34550, with d, name, description, image, moderator p tags and relay hints. Posts now use NIP-22 kind 1111 comments scoped to the community through uppercase and lowercase tags.
Approval events use kind 4550. They let moderators approve events into the community stream. The model supports top-level posts, nested replies and backwards compatibility with older kind 1 community posts.
The design is moderator-centered. That can work for public topic spaces, but it also creates complexity around approvals, cross-posting and relay behavior.
A once-central community NIP became unrecommended
Vitor Pamplona's 2023 work shaped much of NIP-72: preferred relay tags, post approval, replaceable events, relay markers and unapproval behavior. Jon Staab later clarified moderation and cross-posting. In July 2025, Alex Gleason changed text notes to use kind 1111.
In May 2026, fiatjaf added the unrecommended tag and warning to NIP bodies. That is the turning point you need to know. NIP-72 remains part of the archive because it exists and has implementations, but it is not the preferred direction for new group design.
Nostrbook's group comparison notes that NIP-72 has been implemented by clients such as Amethyst, nostrudel, Satellite and Coracle, while also framing it as one of several group approaches.
Existing support matters, but new builds needs to look at NIP-29
Clients with existing NIP-72 support needs to still render communities correctly, respect approval events and show moderator identity clearly. Users may encounter old community events for a long time.
For new builds, the official warning points to NIP-29. That does not erase NIP-72; it changes how the page guides people. Treat it as legacy or transitional community infrastructure unless a specific client ecosystem requires it.
A good UI distinguishes approved posts from merely tagged posts and shows whether the community model is NIP-72 or another group standard.
Community standards can fragment the social layer
NIP-72's biggest risk is not that it never worked. It is that competing group models can split clients and confuse users. A post may be visible in one community client and absent in another.
Moderation authority also needs clear display. A community definition is signed by a pubkey; that pubkey and its moderators needs to be visible, not hidden behind a generic community name.
Read NIP-72 in the wild
NIP-72 captures moderated community patterns. It matters because communities need more than posts: they need topics, roles, moderation and a shared room people can recognize.
The ecosystem has explored several community designs, so treat this as one branch of the conversation. Compare it with relay-based groups and forum threads before building your whole social layer around it.
What changes when you actually use it
For you, NIP-72: Moderated Communities is felt when someone makes a claim about content, people, trust, status or community behavior. Reports, labels, badges, assertions and polls can help you navigate an open network, but they can also become quiet authority. Read NIP-29, NIP-22, NIP-09 so you see who speaks, what is targeted and how much weight the claim deserves.
What changes for builders and operators
For builders and moderators, NIP-72: Moderated Communities means preventing claims from becoming invisible law. Show issuer, target, reason, timestamp, evidence and conflict. Let people understand why a label, report, badge or assertion appears before it changes what they can see.
What the official file makes concrete
The official file is organized around Community Definition, Posting to a community, Top-level posts, Nested replies, Backwards compatibility note, Moderation, Cross-posting. Inspect kind 34550, kind 4550, kind 0, kind 1111, kind 1, kind 6, kind 16, unrecommended because these are the pieces most likely to surface as product behavior. Read it beside NIP-29, NIP-22, NIP-09 before treating it as isolated.
NIP-72: Moderated Communities is a claim layer. Reports, labels, badges, assertions and polls only help when issuer, target and scope stay visible.
Where it breaks
The failure mode in NIP-72: Moderated Communities is authority theater. A report, label, badge, assertion or poll can look official because it is signed and rendered cleanly. The signature proves the issuer, not the fairness or accuracy of the claim.
Where this appears outside the markdown
In the ecosystem, NIP-72: Moderated Communities belongs to the social safety and coordination layer. It can help people filter noise, recognize contribution, report abuse, run polls or make assertions. It can also concentrate influence quietly if the issuer disappears behind the label. The hub has to preserve that tension instead of selling governance as solved.
The nearby-standard trap
The nearby-standard trap in NIP-72: Moderated Communities is treating every signed claim as a moderation decision. A label, report, badge, assertion or poll can inform judgment without becoming policy. Read NIP-29, NIP-22, NIP-09 and keep issuer, target and consequence separate.
Language that keeps the feature honest
Good product copy for NIP-72: Moderated Communities names the claimant. It says who reported, labeled, awarded, asserted, voted or counted, and it leaves room for conflict. That is how a safety feature avoids becoming invisible authority.
What this page does not promise
NIP-72: Moderated Communities does not make a community decision neutral. Signed reports, labels, badges, assertions and polls can improve safety or discovery, but they still come from people, services or institutions with incentives. The standard helps expose the claim. It does not make the claim fair, complete or universally binding.
Read it as a field test
Start NIP-72: Moderated Communities with the claimant. A label, report, badge, assertion or poll has meaning only when issuer, target, reason and consequence remain visible. The article needs to preserve that social context because signed data can still be biased, stale or disputed.
Where the standard earns trust
The source links give you places to test the interpretation in public: NIP-29 Relay-based Groups, Nostrbook group comparison, Amethyst, nostrudel. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-72 source is the anchor for exact wording, and NIP-72 commit history shows how that wording moved over time. The strongest secondary clues here are NIP-29 Relay-based Groups, Nostrbook group comparison, Amethyst. 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-72: Moderated Communities: first the human promise, then kind 34550, kind 4550, kind 0, kind 1111, kind 1, kind 6, then the implementation record, then the real-world failure case. That order keeps NIP-72 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who issued the claim, label, badge, report, assertion or poll, and what exactly is the target?
- Can you see evidence, conflicts, expiry and scope before the claim changes what you see?
- Does the design leave room for disagreement instead of hiding authority behind a clean badge?
What to verify before you rely on it
- Find
kind 34550,kind 4550,kind 0,kind 1111,kind 1in the official file and check where the UI exposes the same concept. - Read NIP-29, NIP-22, NIP-09 as context before treating NIP-72 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-72: Moderated Communities in that order: Official NIP-72 source for the current wording; NIP-72 commit history for the change record; NIP-29 Relay-based Groups, Nostrbook group comparison, Amethyst 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.
