Comparing Community-specs

This is a comparison of four approaches to communities on Nostr: Communikeys, NIP-29 (Relay-based Groups), NIP-72 (Moderated Communities), and Chorus (modified NIP-72).

Relay Requirements

Communikeys

Works on any standard Nostr relay. No special relay implementation is required. Access control is enforced client-side by checking badge ownership. Relays MAY optimize for Communikeys, but it's optional.

NIP-29

Requires a specialized relay that implements group-specific logic. The relay must generate and sign group metadata events, enforce membership rules, handle moderation events, manage roles and permissions, and validate timeline references. If the relay goes down, the group becomes inaccessible.

NIP-72

Works on standard relays but relies on moderator approval events. The community definition event specifies preferred relays for requests and approvals. Does not require special relay software, but the approval workflow depends on moderator availability.

Chorus

Works on standard relays. Uses membership lists (approved, declined, banned) stored as addressable events. Access control depends on clients checking these lists. See github.com/andotherstuff/chorus.

---

New Event Kinds Introduced

Communikeys

2 event kinds:

• kind:10222 — Community Definition
• kind:30222 — Targeted Publication

Uses existing primitives for everything else: badges (NIP-58), forms (NIP-101), profile metadata (kind:0).

NIP-29

15+ event kinds:

• kind:9000-9009 — Moderation events
• kind:9021 — Join request
• kind:9022 — Leave request
• kind:39000 — Group metadata
• kind:39001 — Group admins
• kind:39002 — Group members
• kind:39003 — Group roles

NIP-72

2 event kinds:

• kind:34550 — Community Definition
• kind:4550 — Post Approval

Chorus

11 event kinds:

• kind:4550 — Post approval
• kind:4551 — Post removal
• kind:4552 — Join request
• kind:4553 — Leave request
• kind:4554 — Close report
• kind:34550 — Community definition
• kind:34551 — Approved members list
• kind:34552 — Declined members list
• kind:34553 — Banned members list
• kind:34554 — Pinned posts list
• kind:34555 — Pinned groups list

---

Targeting Existing Publications

Communikeys

Any existing Nostr event can be targeted to a community via a Targeted Publication event (kind:30222). Full backwards compatibility with existing content. The targeted publication is a separate event, so the association can be updated or removed without affecting the original content.

NIP-29

Events must be created specifically for the group with an h tag and timeline references. Existing publications cannot be retroactively added. Once published to a group, content is permanently tied to that group — articles, apps, docs, books cannot be disassociated.

NIP-72

Events must include the community's a tag when created. Cross-posting via NIP-18 reposts is possible, but the original event is not directly part of the community. Content created for a community is permanently associated with it.

Chorus

Same as NIP-72. Events must reference the community when created. Content is permanently tied to the community it was posted to.

---

Multi-Community Targeting

Communikeys

A single publication can be targeted to up to 12 communities via one Targeted Publication event.

NIP-29

Events belong to exactly one group. Cross-posting requires creating separate events.

NIP-72

Limited cross-posting via reposts. Creates duplicate content rather than true multi-targeting.

Chorus

Same as NIP-72.

---

Write Access Control

Communikeys

Content sections (Chat, Posts, Articles) have specific event kinds and badge requirements. Multiple badges can grant access to the same section. Granular, per-content-type permissions.

Badge requests can include Forms (NIP-101), allowing communities to require anything from prospective members: email verification, captcha, payments, invite codes, questionnaires, etc. All requirements are transparent — defined in the Badge Definition and Form Template events — so users and apps can see exactly what's needed. No other spec offers this flexibility for gating access.

NIP-29

Group-wide access managed by roles. Roles grant capabilities (delete, edit, etc.) but no content-type-specific control. Role definitions and permissions are relay-specific and non-standardized — each relay can define its own roles and what they can do. This makes interoperability difficult for clients, as access rules are invisible and vary between relays.

NIP-72

Moderator approval controls publication. No content-type-specific permissions.

Chorus

Membership lists (approved, declined, banned) control who can participate. Join/leave request system. No content-type-specific permissions.

---

Client Filtering Complexity

Communikeys

1. Fetch the community's kind:10222 event
2. Query for events of specified kinds targeting the community
3. Filter by badge ownership

Standard Nostr queries, client-side filtering.

NIP-29

1. Connect to specific group relay
2. AUTH for private groups
3. Handle relay-signed metadata
4. Track timeline references
5. Process moderation state

Relay handles access control; clients need NIP-29-specific logic.

NIP-72

1. Query for community posts
2. Query for approval events
3. Match posts to approvals

Chorus

1. Query for community posts
2. Query for membership lists
3. Filter by membership status

---

Infrastructure Burden

Communikeys

Brands use their existing npub as the community identifier. Brands and businesses already need nsec/keypair management for their brand profile on Nostr — Communikeys simply reuses this infrastructure. No new admin systems to learn.

Badge awarding can also be delegated to a separate keypair, allowing assistants or automated systems to handle membership without access to the main brand keypair. This separation means routine admin tasks don't risk security-sensitive operations.

NIP-29

Groups identified by relay-specific IDs. Brands must run their own NIP-29 relay or depend on third-party operators. Role system is relay-defined.

NIP-72

Communities are separate addressable events, not tied to a brand's npub. Requires moderator workflow management.

Chorus

Similar to NIP-72. Communities are separate from brand identity. Requires managing membership lists and approval workflows.

---

New User Onboarding

Communikeys

New users joining Nostr via a community need zero personal infrastructure. The community definition event specifies:

• Relay(s) for publishing and reading
• Blossom server(s) for media
• Cashu mint(s) for payments

A new user can generate a keypair and immediately start participating using the community's infrastructure. No relay configuration, no media server setup, no wallet integration needed on day one.

NIP-29

New users must connect to the specific group relay. The relay handles everything, but users still need to understand relay configuration. No built-in media or payment infrastructure.

NIP-72

New users must configure their own relay list (NIP-65) for their profile. The community specifies preferred relays for requests/approvals, but users still publish from their own relay configuration. No integrated media or payment solution.

Chorus

Similar to NIP-72. Users need their own relay configuration. Community may specify relays, but no integrated onboarding for media or payments.

---

Summary

Communikeys

• Works on any relay
• 2 new event kinds
• Can target existing content
• Can target multiple communities
• Per-content-type access control
• Low client complexity
• Uses brand's npub
• Badge-based access
• Full new user onboarding (relay, media, payments)

NIP-29

• Requires specialized relay
• 15+ new event kinds
• Cannot target existing content
• Single-group targeting only
• No per-content-type access
• High client complexity
• Relay-specific group IDs
• Role-based access
• Relay-only onboarding

NIP-72

• Works on any relay
• 2 new event kinds
• Target existing content via repost
• Multi-targeting via repost
• No per-content-type access
• Medium client complexity
• Separate community identity
• Approval-based access
• No integrated onboarding

Chorus

• Works on any relay
• 11 new event kinds
• Target existing content via repost
• Multi-targeting via repost
• No per-content-type access
• Medium client complexity
• Separate community identity
• Membership list access
• No integrated onboarding