Comparing Nostr Group Implementations

This document compares different approaches to implementing group functionality in the Nostr protocol, as defined in different NIPs, as well as alternative community structures like Ditto.

Comparison Summary

Feature	NIP-28	NIP-72	NIP-29	NIP-EE	Ditto	NIP-87
Primary Focus	Public chat channels	Reddit-style communities	Closed group management	E2EE messaging (MLS)	Domain-based communities	Private encrypted groups
Group Identifier	Event ID (kind 40)	Replaceable event (34550)	Random string with relay host	MLS Group ID (private) + Nostr Group ID	NIP-05 domain	Admin key address
Access Control	Client-side moderation	Moderator approval	Relay-enforced	E2EE with admin control	Admin-controlled relay	Encryption-based
Privacy	Public only	Public only	Configurable	Strong E2EE (MLS protocol)	Public by default	Strong encryption
Membership	Open to all	Open to all	Can be restricted	Invite-based with key packages	Domain registration	Key-based membership
Event Tags	"e" tags	"a" tags	"h" tags	"h" tags + MLS encryption	Standard Nostr events	Encrypted wrapping
Complexity	Low	Medium	High	Very High (MLS-based)	Medium	High
Client Support	Amethyst, Iris	Amethyst, nostrudel, Satellite	0xChat, chachi.chat	whitenoise	Ditto	Coracle (deprecated)

NIP-28 (Public Chat)

NIP-28 defines a simple approach to public chat channels with client-side moderation. It is implemented by Amethyst and Iris.

Key Concept

• Public chat channels accessible to everyone
• Uses event IDs (of kind 40) as channel identifiers
• Client-side moderation with no central authority
• Simple event referencing using "e" tags

Technical Approach

• Kind 40: Create a new chat channel
• Kind 41: Update channel metadata
• Kind 42: Send message to channel
• Kind 43: Hide/moderate a message
• Kind 44: Mute a user in channel context

Unique Features

• Lowest implementation complexity
• No access restrictions or permissions
• Clients decide which content to display
• Recommended relays in metadata (but not enforced)
• Thread-based message context

NIP-72 (Moderated Communities)

NIP-72 defines Reddit-style communities with post approval by moderators. It is implemented by Amethyst, nostrudel, Satellite, and Coracle (deprecated).

Key Concept

• Topic-focused communities with moderation
• Uses replaceable events (kind 34550) as community identifiers
• Moderator-based approvals system for content
• Any event kind can be posted to a community using "a" tags

Technical Approach

• Kind 34550: Community definition with moderator list
• Kind 4550: Post approval by authorized moderators
• Post to community: Tag any event with community "a" tag
• Community creator defines moderators
• Moderators can delete their approvals (NIP-09)

Unique Features

• Medium implementation complexity
• Content curation through moderator approvals
• No membership restrictions
• Public communities visible to everyone
• Post and comment style content organization

NIP-29 (Relay-based Groups)

NIP-29 defines relay-enforced groups with comprehensive moderation. It is implemented by 0xChat, chachi.chat, groups.nip29.com, and Flotilla (partially).

Key Concept

• Relay-enforced group management and access control
• Uses random string IDs with relay host as group identifiers
• Configurable privacy and access settings
• Hierarchical role-based permissions
• Events identified by "h" tag

Technical Approach

• Kinds 9000-9020: Comprehensive moderation events
• Kind 9021/9022: Join/leave requests
• Kind 39000-39003: Group metadata, admins, members, and roles
• Timeline references to prevent out-of-context messages
• Relay generates and enforces group state

Unique Features

• Highest implementation complexity
• Configurable as public/private and open/closed
• Strong access control with invite codes
• Specialized relays required for implementation
• Comprehensive moderation capabilities

NIP-EE (E2EE Messaging with MLS)

NIP-EE is a proposed NIP that defines a comprehensive end-to-end encrypted messaging system using the Messaging Layer Security (MLS) protocol. It is currently open for review but not yet merged into the official NIPs.

Key Concept

• Leverages the MLS protocol (RFC 9420) for secure, scalable E2EE group messaging
• Strong privacy and confidentiality guarantees
• Forward secrecy and post-compromise security
• Two-level group identification: private MLS Group ID + public Nostr Group ID
• Ephemeral keypairs for publishing group events
• Designed to work efficiently for both 1:1 and large group communications

Technical Approach

• Kind 443: KeyPackage Event - allows users to be added to groups asynchronously
• Kind 444: Welcome Event - used to add new members to groups via NIP-59 gift-wrapping
• Kind 445: Group Event - all messages within a group (control and application messages)
• Kind 10051: KeyPackage Relays List - indicates where users publish KeyPackage Events
• Uses MLS protocol for managing group state, membership, and encryption
• Required MLS extensions, including custom nostr_group_data extension
• Uses the MLS exporter_secret for additional encryption via NIP-44

Unique Features

• Highest implementation complexity but strongest security properties
• Complete end-to-end encryption with strong forward secrecy
• Separation of Nostr identity keys from group signing keys
• Efficient key management even for large groups (logarithmic vs linear complexity)
• Allows multiple devices per user through separate client credentials
• Designed to preserve metadata privacy through obfuscation
• Inner unsigned Nostr events for application messages (kinds 7, 9, etc.)

Security Considerations

• Forward secrecy and post-compromise security through key rotation
• Protection against key compromise through separation of keys
• Metadata protection through ephemeral keypairs and obfuscation
• Graceful handling of race conditions in distributed environments
• Extensive recommendations for client-side security practices

Ditto (Domain-based Communities)

Ditto is a full-stack Nostr server with a dedicated UI and admin control over its relay. It takes a different approach to community building, similar to Mastodon but using Nostr as the decentralized protocol instead of ActivityPub.

Key Concept

• Domain-based communities with integrated relay service
• Uses NIP-05 domain names as the community identifier
• Admin-controlled relay with moderation capabilities
• Users on a Ditto instance can view feeds from any NIP-05 domain
• Full Nostr protocol compatibility with specialized UX

Technical Approach

• Standard Nostr events and relays (no special event kinds)
• NIP-05 verification for all users on the instance
• Controlled relay that can filter content
• Default local and federated timeline views
• Admin tools for managing the instance and users

Unique Features

• Makes joining Nostr accessible through familiar server-based model
• Users get automatic NIP-05 verification on registration
• Community feeling through domain association
• Easier discovery of other users within the instance
• Admin control over relay content and moderation
• Ability to view feeds from other Nostr instances/domains

Group Visibility and Access

• Public by default, but admin has control over relay content
• Membership through domain registration
• No explicit group containers - community defined by domain
• Federated view of the Nostr network
• Local timeline for instance-specific content

NIP-87 (Encrypted Groups)

NIP-87 was proposed but never merged into the official NIPs. It was implemented by Coracle.

WARNING

This proposed NIP was closed by the author and should not be used to build new projects.

Key Concept

• Two-tier key system: admin key + shared key
• Possession of the shared key constitutes membership
• Complete encryption of all group content
• Anonymous participation possible through alternate keypairs

Technical Approach

• Uses NIP-59 event wrapping to encrypt any Nostr event
• Key rotation with weak forward secrecy
• Event kinds 24-28 for membership management
• Kinds 1985, 10024, 10025 for moderation and metadata

Unique Features

• Privacy-first design (unlike other group NIPs)
• Flexible moderation: whitelist, blacklist, or none
• Public or private group metadata
• Members choose whose moderation opinions to follow

Events and Kinds

NIP-28 (Public Chat)

• Kind 40: Create channel
• Kind 41: Set channel metadata
• Kind 42: Create channel message
• Kind 43: Hide message (moderation)
• Kind 44: Mute user (moderation)

NIP-72 (Moderated Communities)

• Kind 34550: Community definition (replaceable event)
• Kind 4550: Post approval by moderators
• Any kind can be posted to a community using "a" tags

NIP-29 (Relay-based Groups)

• Kind 9000-9020: Moderation events (e.g., put-user, remove-user)
• Kind 9021: Join request
• Kind 9022: Leave request
• Kind 39000: Group metadata
• Kind 39001: Group admins
• Kind 39002: Group members
• Kind 39003: Group roles
• Regular kinds (1, 42, etc.) with an "h" tag for group context

NIP-EE (E2EE Messaging with MLS)

• Kind 443: KeyPackage Event
• Kind 444: Welcome Event (gift-wrapped via NIP-59)
• Kind 445: Group Event (all group messages)
• Kind 10051: KeyPackage Relays List
• Inner application messages use standard kinds (1, 7, 9, etc.)

Moderation Approaches

NIP-28

• Client-side moderation
• Users can hide messages (kind 43)
• Users can mute other users (kind 44)
• No central authority for moderation
• Clients decide which content to show

NIP-72

• Moderator-based approvals system
• Community creator defines moderators in the community definition event
• Moderators issue approval (kind 4550) events for posts
• Content must be approved to appear in the community
• Moderators can delete their approval using NIP-09

NIP-29

• Relay-enforced moderation
• Hierarchical role-based permissions
• Relay generates group metadata events
• Admins can be assigned with different roles (customizable)
• Comprehensive moderation actions (put-user, remove-user, edit-metadata, etc.)
• Timeline references to prevent out-of-context messages

NIP-EE

• Admin-controlled group management
• Configured through the nostr_group_data extension with admin_pubkeys list
• All group members can update their own credentials
• Only admins can update group metadata or membership
• Strong cryptographic verification of all messages and changes

Group Visibility and Access

NIP-28

• Always public
• No access restrictions
• Recommended relays in metadata, but not enforced

NIP-72

• Always public
• No access restrictions
• Relies on post approval system for content control
• Recommended relays in community definition

NIP-29

• Configurable: public or private
• Configurable: open or closed membership
• Invite codes for closed groups
• Can require authentication for private groups
• Group membership can be tracked and enforced

NIP-EE

• Strong E2EE for all group content
• Two levels of identification: private MLS Group ID and public Nostr Group ID
• Group state is not visible to non-members
• Invite-based membership through KeyPackage Events and Welcome Events
• Metadata protection through ephemeral publishing keypairs
• Forward secrecy and post-compromise security through key rotation

Comparison Summary

Feature	NIP-28	NIP-72	NIP-29	NIP-EE	Ditto	NIP-87
Implementation Complexity	Low	Medium	High	Very High	Medium	High
Moderation Effectiveness	Client-side only	Moderator approval	Relay-enforced	Admin-controlled	Admin-controlled relay	Flexible options
Privacy	Public only	Public only	Configurable (public/private)	Strong E2EE	Public by default	Strong encryption
Scalability	Relies on client filtering	Requires moderation overhead	Requires specialized relays	Efficient even for large groups	Federated Nostr model	Limited by key distribution
Use Case	Public chat rooms	Content-focused communities	Private/managed groups	Secure messaging (1:1 and groups)	Familiar server-based social network	Private groups (deprecated)
Message Context	Thread-based	Post and comment style	Group context with timeline references	Encrypted private Nostr feed	Local and federated timelines	Encrypted group feed
Primary Control	Client	Community creator and moderators	Relay and admins	Group admins and MLS protocol	Instance admin	Group admin and members

Suitability

• NIP-28: Best for simple public chat channels with minimal moderation needs.
• NIP-72: Ideal for topic-focused communities with content curation (Reddit-style).
• NIP-29: Most appropriate for private groups, teams, or communities needing strong access control and moderation.
• NIP-EE: Optimal for secure messaging applications requiring strong privacy, confidentiality, and forward secrecy.
• Ditto: Well-suited for users familiar with server-based social networks (like Mastodon) who want an easy onboarding to Nostr with automatic NIP-05 verification and a domain-based community feel.
• NIP-87: Not recommended for new projects as this proposal was withdrawn by the author.

Implementation Status

All NIPs discussed (NIP-28, NIP-72, NIP-29, and NIP-EE) are marked as draft and optional, indicating they are still evolving and not required for basic Nostr protocol compliance. NIP-87 was withdrawn and should not be used for new projects. Different clients may implement one or more of these approaches based on their specific use cases and requirements.

Client Implementations

Here's a list of known clients that implement each group NIP:

NIP-28 (Public Chat)

• Amethyst
• Iris

NIP-72 (Moderated Communities)

• Amethyst
• nostrudel
• Satellite
• Coracle (deprecated)

NIP-29 (Relay-based Groups)

• 0xChat
• chachi.chat
• groups.nip29.com
• Flotilla* (partially implemented)

NIP-EE (E2EE Messaging with MLS)

• whitenoise

Ditto (Domain-based Communities)

• Ditto