NIP-29: Relay-based Groups
Communities needed relay-enforced rules
NIP-29 is the answer to the limits of NIP-28. Public chat channels are easy to create, but real groups need authority somewhere: who can read, who can write, who can moderate, who can invite, which relay hosts the canonical state and how clients know what room they are in.
The NIP chooses a relay-based model. A group is identified by an arbitrary group ID, and events sent to the group carry an h tag with that ID. The relay can enforce membership, reject unauthorized moderation events, sign group metadata and expose group admins, members, roles and live participants.
This is not pure client-side anarchy. It is a pragmatic model for communities that want Nostr identity and portable events while still allowing a relay to enforce local policy. A group can be public or private, open or closed, hidden or visible, text-only or connected to live audio/video.
Group IDs, h tags, roles and relay-signed state
User-created group events include an h tag with the group ID. Normal content can be any supported kind: chat messages, text notes, comments, long-form articles, calendar events, livestreams or other objects. The group layer does not replace those NIPs; it scopes them to a relay-managed community.
Group metadata lives in addressable events signed by the relay's own key. Kind 39000 describes the group, kind 39001 lists admins, kind 39002 can list members, kind 39003 describes supported roles and kind 39004 can list live AV participants. The group can be referenced through an naddr pointing at kind 39000 with the relay self pubkey.
Management and moderation happen through kinds 9000 to 9022: put user, remove user, edit metadata, delete event, create group, delete group, create invite, join request and leave request. The relay checks whether the pubkey has permission to perform the action according to its local role policy.
NIP-29 moved from simple groups into a full community substrate
The current NIP-29 lineage starts with Jon Staab adding an imeta tag in late 2023, then Alex Gleason and fiatjaf reshaping the file in early 2024. Fiatjaf's February 2024 Simple Groups PR #566 established the relay-based group direction.
The file then changed rapidly. 2024 brought addressable-event terminology, leave requests, delete-group events, role simplification, invite-code changes, moderation-table refinements and a split of chat/thread behavior out of the group spec. Jon Staab contributed naming and join-request feedback changes. Hodlbod clarified closed/private/hidden behavior.
The 2026 commits show the standard still alive: relay-key clarification, removal of unmanaged groups, edit-metadata semantics, deletion of a weak group identifier recommendation and, in May 2026, LiveKit audio/video spaces. NIP-29 is not a frozen chat toy. It is becoming the governance layer for relay-hosted communities.
NIP-29 is already a real app and relay surface
The implementation trail is stronger than you may expect. Nostrbook's group documentation says NIP-29 is implemented by 0xChat, chachi.chat, groups.nip29.com and Flotilla. A dedicated Groups client by max21dev presents itself as a NIP-29 group chat client. verse-pbc's groups_relay repository lists support for event kinds 9000-9009, 9021-9022 and 39000-39003, while noting timeline references are not implemented.
@nostr/tools exposes NIP-29 helper documentation for loading group metadata, admins and members. 0xChat's Dart library lists NIP-29 support. A Hacker News launch for Mesh describes a Slack-like team chat built on NIP-29 relays with a Rust backend and Next.js frontend. OpenSats describes Coracle and Flotilla as production testing grounds for relay-related protocol improvements.
The hardest implementation detail is not drawing a room list. It is deciding what the relay enforces, how clients show relay authority, how forks are handled, how timeline references prevent out-of-context replay and how join requests communicate failure, pending review, payment requirements or invite-code rules.
Relay-based groups trade purity for enforceable community state
NIP-29's strength is also its tension. A relay can enforce policy, but that means the group depends on that relay's availability, moderation philosophy and implementation quality. Groups can move or fork, yet the user experience around forks can become confusing quickly.
The second risk is partial implementation. A relay that skips timeline references, a client that ignores role metadata or a group that cannot explain private/closed/hidden differences will feel inconsistent. NIP-29 gives a serious framework, but communities still need careful operational design.
Read NIP-29 in the wild
NIP-29 puts groups at the relay layer. That is a different social contract from a free-floating hashtag or a client-only room: the relay can define group membership, moderation and server-side rules.
This can make communities more practical, but it also gives the relay more power. You gain clearer rooms and lose some neutrality. The product has to show which relay governs the group and what happens when you leave it.
What changes when you actually use it
For you, NIP-29: Relay-based Groups is felt inside the room: who can read, who can reply, what remains visible and what the interface makes private by implication. Messaging standards are risky because familiar chat design can smuggle in promises the protocol never made. Read NIP-98, NIP-11, NIP-51 as the surrounding map before trusting the room label.
What changes for builders and operators
For builders, NIP-29: Relay-based Groups is expectation control. Test the same conversation across relays, devices and clients. Make audience, persistence, encryption and moderation visible. A chat-shaped interface can feel private even when the event is public, and that mismatch is a product bug.
What the official file makes concrete
The official file is organized around Relay-generated events, Group identifier, The h tag, Timeline references, Late publication, Group management, Live audio/video (AV) spaces, Event definitions. Inspect kind 39000, kind 39003, kind 9000, kind 39001, kind 9021, kind 9009, kind 9022, kind 9001 because these are the pieces most likely to surface as product behavior. Read it beside NIP-98, NIP-11, NIP-51 before treating it as isolated.
NIP-29: Relay-based Groups needs honest audience language. Public, private, group, encrypted, temporary and moderated are different promises.
Where it breaks
The failure mode in NIP-29: Relay-based Groups is false intimacy. The room feels like a messenger, but storage, audience, reply context or metadata tell a more public story. This is where copywriting, UI labels and protocol behavior need to match exactly.
Where this appears outside the markdown
In the ecosystem, NIP-29: Relay-based Groups touches the most emotionally familiar interface: a conversation. That makes it easy for products to borrow the comfort of chat, groups or DMs while the actual protocol object has different privacy and delivery properties. The page has to slow that moment down before the interface creates a false expectation.
The nearby-standard trap
The nearby-standard trap in NIP-29: Relay-based Groups is using one room word for several protocols. Chat, public chat, private DM, group, forum thread, comment and encrypted envelope are different. Read NIP-98, NIP-11, NIP-51 and keep the interface honest about which promise is actually present.
Language that keeps the feature honest
Good product copy for NIP-29: Relay-based Groups names the room. It says public, encrypted, relay-scoped, group-controlled, archived, temporary or moderation-aware when those things are true. It avoids borrowing private-message comfort for data that travels more openly.
What this page does not promise
NIP-29: Relay-based Groups does not turn every conversation into a private room. A chat-like screen can hide public relays, visible metadata, partial delivery, missing devices or moderation rules that only live on one server. The safe reading is concrete: who can read, where does the event live, what does encryption cover, and what happens when one client leaves?
Read it as a field test
Start NIP-29: Relay-based Groups with the audience. A message-like interface earns trust only when public, private, encrypted, group-scoped and relay-scoped behavior are not blurred. Read NIP-98, NIP-11, NIP-51 before drawing product conclusions, because most messaging mistakes come from using the wrong room model for the event in front of you.
Where the standard earns trust
The source links give you places to test the interpretation in public: nips.nostr.com NIP-29 mirror, Nostrbook group comparison, max21dev Groups client, Groups Relay. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-29 source is the anchor for exact wording, and NIP-29 commit history shows how that wording moved over time. The strongest secondary clues here are nips.nostr.com NIP-29 mirror, Nostrbook group comparison, max21dev Groups client. 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-29: Relay-based Groups: first the human promise, then kind 39000, kind 39003, kind 9000, kind 39001, kind 9021, kind 9009, then the implementation record, then the real-world failure case. That order keeps NIP-29 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who can read the event, and does the screen say that before you type?
- What metadata remains visible even when content is encrypted or wrapped?
- Can another client recover the thread, room or message history without pretending delivery is guaranteed?
What to verify before you rely on it
- Find
kind 39000,kind 39003,kind 9000,kind 39001,kind 9021in the official file and check where the UI exposes the same concept. - Read NIP-98, NIP-11, NIP-51 as context before treating NIP-29 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-29: Relay-based Groups in that order: Official NIP-29 source for the current wording; NIP-29 commit history for the change record; nips.nostr.com NIP-29 mirror, Nostrbook group comparison, max21dev Groups client 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.
