Relay groups, NIP-29 and rooms that belong to relays
A Nostr group is not automatically a universal cloud community. Under NIP-29, a group is a room hosted by a relay, shaped by relay policy, described by relay-signed metadata and enforced close to storage.
A relay group belongs somewhere
Nostr is famous for portable identity, but a group needs a place. A real room has rules, members, moderators, history, access, context and a boundary between inside and outside. NIP-29 puts that boundary at the relay. The relay hosts the group, enforces the group's rules and signs the group metadata that clients use to display it.
That design is important because groups are social infrastructure, not just message streams. A group may be a private team, public club, local meetup, conference room, paid community, support channel, media salon, trading room, class, venue room or live AV space. Each of those needs different membership, moderation and retention. A global one-size group primitive would either be too weak for serious rooms or too centralized for open protocol culture.
NIP-29 starts from a practical fact: there is no universal way to create a group across all relays. Instead, a relay can create rules around a specific group id. Messages sent with that id become subject to the relay's group rules. The group originally belongs to one relay, but a community may later move or fork it so the same id exists in different forms on different relays. That is messy, but honest. Rooms have homes, and homes can split.
This also explains why relay groups are different from plain public notes. A public note can be copied to many relays and read anywhere that stores it. A NIP-29 group message is contextual. It carries an h tag and may include timeline references to previous events seen on the same relay. It is meant to be understood inside that room's state, not as a free-floating post stripped of room context.
If you use NIP-29, keep one sentence in your head: the relay is not only transporting the room; it is part of the room. That has consequences for trust, moderation, portability and UX.
The h tag is the room door
Events sent by users to NIP-29 groups must include an h tag whose value is the group id. That small tag is the room door. It tells the relay and client which group context the event belongs to. Chat messages, text notes, moderation events and other supported event kinds can use the same group id, as long as the relay supports them for that room.
The group can also be identified by an naddr1 code that points to the group metadata event: kind 39000, the relay's self public key, the d identifier set to the group id and a relay hint to the hosting relay. That matters because the metadata is relay-generated. The room is not just a hashtag. It is an addressable object rooted in a relay's public key and metadata.
The difference between a hashtag and an h tag is the difference between a topic and a room. A hashtag can collect public discussion from many relays. A NIP-29 group id points into a relay-enforced context. If a client treats the h tag like a casual topic tag, it will misunderstand membership, moderation and fork behavior.
Clients should show the relay context clearly. "Nostr Builders on relay.example" is more honest than "Nostr Builders" floating in nowhere. If the same group id appears on another relay, that may be a fork, migration or unrelated room using the same id. Users need to see which relay they are inside before they trust the group state.
For users, the practical question is simple: which room am I posting into? If you cannot tell the relay, membership state, privacy flag and supported event kinds, you do not yet understand the room.
Group metadata and roles are relay-signed context
NIP-29 defines relay-generated metadata events. The group metadata event, kind 39000, includes a d tag with the group id and can include tags such as name, picture, about, private, closed, restricted, hidden, livekit and supported_kinds. This is how clients know what the room is and how to display it.
The relay signs this metadata with its relay keypair, using the relay self public key exposed through NIP-11. That is a crucial trust detail. A random user should not be able to publish fake metadata that makes the room look official. The relay's signature says: this is the room state as this relay presents it.
The tags carry real meaning. private means only members can read group messages. restricted means only members can write. hidden means the relay should hide group metadata from non-members. closed means join requests are ignored unless a special path such as an invite code is used. supported_kinds tells clients what event kinds the group supports. An empty supported_kinds can even describe AV-only groups.
Roles sit beside metadata. NIP-29 lets relays define role labels and their privileges. A user can receive roles through a kind:9000 moderation event with their pubkey in a p tag and role labels afterward. The role meanings are relay policy. One relay may use admin, moderator, owner, host, speaker or member in different ways. Clients should not assume every label means the same thing everywhere.
Role information can be exposed through group admin and role metadata events such as kind 39001 and kind 39003. The details matter less than the principle: group authority should be inspectable. If someone can remove users, delete events, create invites or edit metadata, clients should be able to show that role rather than hiding power inside the relay.
Join, leave and moderation are signed group events
NIP-29 defines user-related group management events. A join request uses kind 9021 with the group id in the h tag and optional content explaining why the user wants to join. It may include a code tag for invite-based admission. The relay must reject a request if the user has not been added to the group, and the error message should explain whether rejection is final, pending review or tied to something like payment.
A leave request uses kind 9022. A user can send it to be removed from a group. The relay responds by issuing a kind 9001 event that removes the user. That sounds simple, but it is powerful: leaving is part of the group state, not only a local UI action. A serious client should not pretend you left unless the relay actually processed the group state.
Moderation events live in the kind 9000-9020 range. Examples include 9000 for putting or updating a user, 9001 for removing a user, 9002 for editing metadata, 9005 for deleting an event, 9007 for creating a group, 9008 for deleting a group and 9009 for creating an invite. The relay must check whether the pubkey sending a moderation event has the role needed to perform that action.
That relay check is the heart of the model. Users and admins may publish signed events, but the relay enforces the room. If an unauthorized key sends 9005 to delete an event, the relay should reject it. If an authorized moderator sends it, the group state can change. The room is protocol-visible, but enforcement is local to the hosting relay.
For users, this means group moderation is not a vague platform mood. It can be represented as signed events. You can ask who removed a user, which event was deleted, which metadata changed and which roles exist. The relay may not expose everything in a friendly way yet, but the protocol design points toward visible room governance.
Timeline references protect context when rooms fork
NIP-29 includes a clever, slightly gritty idea called timeline references. Events sent to groups may include a previous tag referencing previous events seen from the same relay. The recommendation is that clients include at least three references from recent events and relays enforce them. The point is to stop messages from being replayed into a forked group out of context.
Why does this matter? Because NIP-29 allows a community to move or fork a group. The same group id may exist on multiple relays in different forms. Without context protection, someone could take a message from one branch and broadcast it into another branch where the surrounding conversation never happened. Timeline references give the relay a way to reject events whose referenced context is not in its database.
This is not a perfect cryptographic theory of history. It is a practical room-safety hack. It acknowledges that group events are contextual and that forks create ambiguity. A client that respects timeline references helps keep group messages anchored to the room where they were actually seen.
NIP-29 also warns against late publication. Relays should prevent messages published now with timestamps from days or hours ago unless they are intentionally open to receiving a moved or forked group. That protects timelines from retroactive insertion. In a public feed, late events can already be confusing. In a group room, they can rewrite social context.
For communities, forkability is both a safety valve and a complication. If a relay operator becomes abusive or disappears, the group can move. If a community splits, the group can fork. But users need to understand which branch they are in. Clients should show relay host, group id, metadata freshness and maybe fork/migration signals when available.
LiveKit support turns groups into live rooms
NIP-29 also includes a path for live audio and video spaces. A group can indicate LiveKit support with a livekit tag in the group announcement or metadata. If a group supports only live AV and not text messages, supported_kinds can be empty. That makes room design flexible: a group can be text-only, AV-only or both.
To join the AV space, a client calls a relay path like /.well-known/nip29/livekit/<group-id> with NIP-98-style authorization. The authorization event should be kind 27235 and include a u tag pointing to that LiveKit token endpoint. The relay then returns the LiveKit JWT and server URL so the client can proceed with the normal LiveKit flow.
This design keeps access control close to group membership. The relay can decide who gets a LiveKit token based on the group's settings. A closed member room can keep AV access limited. A public stage can admit broader participation. A speaker role can matter. That is more coherent than bolting a random video call link onto a chat room.
Live participation can also be represented through kind 39004, which may list participants with participant tags. Clients can subscribe to it and show who is currently live. Again, the relay signs and updates room state. The live room is not just external media. It is connected to the Nostr group context.
For users, the practical UX should be clear: who can read, who can write, who can join audio/video, who is live, and which relay is authorizing access. If a client hides those boundaries, a room can feel more centralized and less trustworthy than it really is.
The client experience should make the room legible
A NIP-29 client should show more than a message list. It should show the group name, host relay, privacy state, write restriction, join state, supported event kinds, admins or moderators, invite status and whether the group supports live AV. It should show whether you are a member, whether your join request is pending, whether the group is closed and whether your post failed because of membership, payment, event kind support or moderation.
The client should also prevent out-of-context posting. It should include appropriate previous tags, handle late publication carefully and warn if you are posting into a fork or a relay that does not match the group you think you joined. A group message sent to the wrong relay is not only a technical mistake. It can be a social mistake.
Group discovery should be scoped. A list of groups from one relay is not a global group directory. A hidden group may not expose metadata to non-members. A private group may not expose messages. A closed group may not honor join requests. The client should state what it knows instead of pretending every room is equally discoverable.
Leaving should be a real state change. If you click leave, the client should send kind 9022 and then check whether the relay issued the removal state. Muting a room locally is different from leaving it. Hiding a room in the client is different from being removed. Good UX gives those actions different names.
Moderation should be visible enough to build trust. You do not need to expose every admin console to every user, but a member should understand why they cannot post, who can moderate, what rules exist and what happened when content was removed. A room with hidden enforcement starts to feel like a platform in miniature.
Operator practice makes or breaks group relays
If you run a relay with NIP-29 groups, start with purpose. Is this a public topic room, a private member room, a local venue room, a conference room, a paid community, a support room, an AV room or a project space? The purpose decides whether messages are public, whether membership is restricted, whether join requests are open, which event kinds are accepted and what moderation needs to exist.
Publish group metadata carefully. The private, restricted, hidden, closed, livekit and supported_kinds tags are not decoration. They are the user's map of the room. If you change access or supported kinds, update metadata. If a room is closed, do not let clients imply open admission. If a room is private, do not leak message previews.
Define roles before conflict. Who can add users? Who can remove users? Who can delete events? Who can edit metadata? Who can create invites? Who can manage LiveKit access? NIP-29 lets role labels be relay-defined, which is flexible, but flexibility without documentation becomes confusion. If your relay uses "host," "mod," "speaker" or "owner," explain what those roles do.
Keep group state reconstructable. NIP-29 expects group state to be reconstructed from the canonical sequence of moderation events. That means you need to store and serve those events reliably. If a relay loses the state sequence, clients may disagree about membership, admins, metadata or removed content. Group relays have an archival duty toward their own governance events.
Plan for moves and forks. If the community may move relays, explain how. If the group forks, help clients identify branches. If you import old state, be careful with late publication and timeline references. Moving a room is not just copying messages. It is migrating trust and context.
When relay groups fit and when they do not
NIP-29 fits when the room needs relay-level enforcement. Private or restricted membership. Local context. Moderation roles. Group-specific event kinds. Live room authorization. Community state. Paid or invite-based access. If those matter, a relay-based group is a natural shape.
NIP-29 may be overkill for casual topic discovery. If you only want a public tag stream, hashtags or communities may be enough. If you want Reddit-style moderated public communities, NIP-72 may be more directly aligned. If you want a simple public chat, NIP-28 may cover part of the experience. The relay group model is strongest when the room has a real boundary.
Local communities are a strong use case. A meetup, coworking space, club, school, hotel, conference or neighborhood room can use a relay group to keep messages, announcements, roles and live access tied to the local relay. The public internet can still exist outside, but the room's memory and rules live near the people using it.
Paid or member communities are another strong use case, as long as the relay is honest about access. NIP-29 can represent member-only writing, invite codes, closed groups and role-based moderation. Payment itself may live outside the NIP, but access can map into group membership. The user should always know whether they are outside, pending, admitted, restricted or removed.
The final question is not "are groups decentralized?" The better question is: can you see the relay, understand the rules, verify the metadata, know your membership state, leave or fork when needed and keep your identity outside the room? If yes, relay groups can give Nostr real rooms without giving up portable identity.
Privacy is a room property, not a vibe
Group privacy has to be precise because users will bring platform expectations with them. A group can be private, hidden, restricted or closed, and those words mean different things. Private is about who can read group messages. Restricted is about who can write. Hidden is about whether group metadata is visible to outsiders. Closed is about whether join requests are ignored except through a special path such as an invite code. If a client collapses all of those into "private group," users will misunderstand the room.
A private group still depends on the relay. The relay can see what it stores unless the content itself is encrypted at the application level. NIP-29 is not an end-to-end encryption spec. It is a relay-based room spec. That means a sensitive group should think about operator trust, hosting, backups, logs, moderation visibility and whether messages should be public, encrypted or avoided entirely. A private room is not automatically a secret room.
Hidden metadata is useful for sensitive groups, but it creates onboarding problems. How do members find the group? How are invites distributed? How does a client explain that a group exists without leaking it to outsiders? A polished product needs separate flows for public discovery, invite-based joining and member-only retrieval. NIP-29 gives the primitives, but the user journey still needs craft.
Restricted writing can be useful even for public rooms. A public announcement channel may let anyone read but only admins post. A local venue may let the public read event announcements but only members respond. A conference room may allow all attendees to read and selected hosts to broadcast. If the UI labels this simply as "public," people may assume they can write. If it labels it as "public read, member write," expectations are clear.
Leaving privacy vague is how communities get hurt. Tell people whether messages are public, member-only, relay-operator-visible, searchable, archived, exportable and removable. You do not need legal prose on every screen. You do need honest room labels.
Group discovery and remembered rooms
NIP-29 mentions using lists to remember groups. A user's kind 10009 event can contain group tags, with group id, relay URL and optional name. That is not global membership proof. It is a way for a user or client to remember which groups matter. It also creates a discovery surface: clients can rebuild a personal group shelf from signed list data.
This matters because group discovery is fragmented by design. One relay may expose its groups. Another may hide them. A private group may not show metadata to outsiders. A client may discover groups through a relay directory, a friend's list, an invite, a link, a community page or a direct naddr. There is no one universal group catalog, and that is not a bug. Rooms should be findable in ways that match their privacy and purpose.
But discovery needs warnings. A group tag in someone's list does not prove you can join. A public group metadata event does not prove the room is active. A group id on one relay does not prove the same room exists on another relay. A forwarded invite code does not prove the inviter still has authority. Clients should treat group discovery as a lead, not as admission.
Group links should carry relay hints clearly. If a user opens a group link and the client silently chooses another relay with the same id, the user may land in a forked or unrelated room. For normal people, this can be invisible and damaging. A good client shows "you are opening this group on relay X" and gives a deliberate path to open alternate relays if they exist.
Remembered rooms also raise social questions. If your group list is public, it can reveal memberships or interests. If it is private or encrypted, portability may be harder. Clients should let users understand whether their group shelf is public, private or local-only. Again, the signed event model gives options; the product needs to make them legible.
Roles are not universal job titles
One of the easiest mistakes is to assume role labels travel cleanly across relays. They do not. A role called "admin" on one relay may include metadata editing, user removal and invite creation. On another relay it may only allow event deletion. A role called "host" may be about LiveKit speaking privileges. A role called "owner" may be social language rather than a protocol guarantee. NIP-29 lets the relay define roles, so clients should display both label and privilege when possible.
Role privilege metadata helps, but human expectations still matter. If a client shows a shiny moderator badge without saying what it means, users will assume too much or too little. A room should be able to show: this person can remove users; this person can delete events; this person can edit metadata; this person can create invites; this person can speak in live rooms. Specific verbs are better than vague status.
Role changes should be visible. If someone becomes a moderator, the room should not feel like the decision happened offstage. If someone loses a role, clients should update. If a compromised admin key changes roles, the community needs to see and recover. Signed moderation events can create a trail, but only if clients surface it and relays preserve it.
Do not confuse relay authority with social authority. A relay can enforce that a key has a role. It cannot guarantee that the person behind the key is trustworthy, wise or socially accepted. Communities still need norms, not only protocol roles. A technically valid moderator can still act badly. A role system gives tools; it does not create culture by itself.
For operators, keep roles small at first. Start with the few powers the room actually needs. Add complexity only when the room grows. A role system with too many labels becomes theater. A room with no role clarity becomes chaos. The good middle is boring: clear powers, visible changes, documented expectations.
Forks, migration and social continuity
The ability to move or fork a group is one of the most Nostr-like parts of NIP-29. If a relay operator disappears, becomes hostile or cannot serve the community anymore, the community should not be trapped forever. But moving a group is not as simple as copying a chat export. The relay signs metadata. The moderation history matters. Membership state matters. Timeline references matter. Users need to know which room is the continuation and which is a fork.
A healthy migration should have a public transition event or at least clear communication from known admins. It should tell members which relay is the new home, what group id is used, what history is preserved, what membership state carries over and what happens to the old relay. Without this, two rooms can both claim continuity and users may split without understanding the conflict.
Forks can be legitimate. A community may disagree and split. One branch may keep the old relay. Another may move. Both can keep the same group id on different relays or create new ids. That is healthier than one operator owning the whole social graph, but it creates UX pressure. Clients should not hide relay identity during a fork. The room name alone is not enough.
Timeline references help prevent messages from being smuggled between branches, but they do not solve social legitimacy. If two branches exist, users will look for signals: known admins, recent messages, membership lists, public explanations, relay reliability, and which branch their peers use. The protocol can keep branches technically distinct; humans still choose where to gather.
Communities should plan migration before crisis. Where would the group go if the relay fails? Who can announce? Which events define the canonical state? Are backups kept? Can members export important history? Can admins recreate roles? A room with no exit plan is easier to capture.
Common mistakes in group clients
The first mistake is hiding the host relay. A NIP-29 group without a visible relay is like a venue with no address. The name may be friendly, but you do not know where you are. Always show the relay in settings, room details and links. When the same group id appears elsewhere, show the difference.
The second mistake is treating membership as local UI state. If the client says you are a member before the relay state confirms it, you will hit confusing failures. If it hides a pending join request, you will think the room is broken. Membership belongs to relay state. The UI should reflect that state, not invent it.
The third mistake is presenting all failures as "message failed." A post can fail because you are not a member, the group is closed, the event kind is unsupported, the timeline references are missing, the relay requires auth, the relay is down, the group was deleted or a moderator removed you. A good client maps relay errors to plain language.
The fourth mistake is ignoring supported event kinds. A group may support chat but not long-form posts, live AV but not text, announcements but not replies. If the client lets you compose an unsupported event, it creates user frustration. Read the group metadata before showing controls. The room should shape the interface.
The fifth mistake is making moderation invisible. If an event disappears, members need to understand whether it was deleted by a moderator, hidden by a local filter, expired, pruned or never accepted. You do not need a public courtroom for every removal, but total silence makes the room feel arbitrary.
Where relay groups meet governance
NIP-29 groups are not a full governance system, but they touch governance immediately. Who creates the group? Who controls metadata? Who admits members? Who defines roles? Who removes users? Who can delete events? Who handles disputes? Who pays for the relay? Who controls the relay key? A room cannot avoid these questions. It can only answer them well or badly.
Because group state is event-based, governance can become more inspectable than in many platform rooms. Admin changes, user additions, removals and metadata edits can be represented as signed moderation events. That does not guarantee fairness, but it gives communities material to examine. "Who removed this?" can have a protocol answer instead of being buried in a company's internal tool.
At the same time, relay control remains powerful. If the operator can rewrite state, hide metadata, stop serving history or restrict access, governance is only as good as the relay's integrity and the community's exit path. That is why relay groups pair naturally with local trust and clear ownership. A room should know who runs the relay and what happens if trust breaks.
For public or semi-public groups, consider publishing a short room charter. Purpose, access, roles, moderation, retention, privacy, live-room behavior and exit plan. It does not need to be heavy. It just needs to reduce surprise. The more the room connects to real people, money, venues or reputation, the more these basics matter.
The cool part is that Nostr does not force all groups into one governance model. A tiny friend room can be informal. A conference room can be event-based. A paid club can be member-managed. A public technical group can be moderator-led. A local venue can be operator-run. The protocol gives room mechanics; communities choose social design.
Why relay groups matter beyond chat
If you only see NIP-29 as group chat, you miss the bigger idea. Relay groups can become local operating rooms for Nostr. They can organize events, announcements, membership, local media, live sessions, voting experiments, badges, venue access, creator circles, support spaces and project coordination. The group is a context layer attached to a relay.
That makes groups useful for real-world networks. A cafe can have a room. A retreat can have a room. A conference can have several rooms. A music collective can have member-only and public rooms. A builder group can have support and governance rooms. Each room can use the same public identity layer while keeping local state where it belongs.
Groups also help products avoid fake globality. Not everything should be broadcast to the whole network. Some things belong in a room, with room rules, room history and room access. NIP-29 lets that happen without making everyone create a new account inside a closed platform. Your key can enter the room; the room does not own your key.
The hard part is restraint. If every app invents hidden NIP-29 semantics, users will get lost. If clients ignore room metadata, rooms will feel broken. If relays run groups without moderation discipline, rooms will decay. The opportunity is real, but it needs careful product work.
When NIP-29 is done well, a group feels local, legible and escapable. You know where you are. You know who can act. You know what the room supports. You know why you cannot post. You can leave. You can follow a migration. You keep your broader Nostr identity. That is a healthier group model than being locked inside someone else's platform account.
Sources worth opening
Open these when you want the group mechanics, related NIPs and implementation context.
- NIP-29: Relay-based groups
- NIP-11: Relay information document and relay self key
- NIP-98: HTTP Auth for LiveKit token requests
- NIP-51: Lists, including remembered groups
- NIP-72: Moderated communities
- NIP-29 relay groups reference site
- LiveKit documentation
- Khatru relay framework for custom relay rooms