I need:
- simplicity
- targeted publication
- incentives for running relays
- unique IDs
- (backwards) compatibility with existing content, relays and profiles
- etc...
Your proposal might work, but it's not what I need.
Article:The Key Pair
What a Nostr key pair has by default:
- A unique ID
- A name
- A description
- An ability to sign stuff
The Relay
What a Nostr relay has (or should have) by default:
- Permissions, Moderation, AUTH, …
- Pricing & other costs to make the above work (cost per content type, subscriptions, xx publications per xx timeframe, …)
- List of accepted content types
- (to add) Guidelines
The Community
Since I need Communities to have all the above mentioned properties too, the simplest solution seems to be to just combine them. And when you already have a key pair and a relay, you just need the third basic Nostr building block to bring them together…
The Event
To create a #communikey, a key pair (The Profile) needs to sign a (kind 30XXX) event that lays out the Community’s :
- Main relay + backup relays
- Main blossom server + backup servers
- (optional) Roles for specific npubs (admin, CEO, dictator, customer service, design lead, …)
- (optional) Community mint
- (optional) “Welcome” Publication that serves as an introduction to the community
This way:
- any existing npub can become a Community
- Communities are not tied to one relay and have a truly unique ID
- Things are waaaaaay easier for relay operators/services to be compatible (relative to existing community proposals)
- Running one relay per community works an order of magnitude better, but isn’t a requirement
The Publishers
What the Community enjoyers need to chat in one specific #communikey :
- Tag the npub in the (kind 9) chat message
What they needs to publish anything else in one or multiple #communikeys :
- Publish a (kind 32222 - Targeted publication) event that lists the npubs of the targeted Communities
- If the event is found on the main relay = The event is accepted
This way:
- any existing publication can be targeted at a Community
- Communities can #interop on content and bring their members together in reply sections, etc…
- Your publication isn’t tied forever to a specific relay
Ncommunity
If nprofile = npub + relay hints, for profiles
Then ncommunity = npub + relay hints, for communities
Wikiquoting= NIP-C0: Communi-keys
naddr1qv…n2y7
This NIP defines a standard for creating, managing and publishing to communities by leveraging existing key pairs and relays, introducing the concept of "Communi-keys". This approach allows any existing npub to become a community (identity + manager) while maintaining compatibility with existing relay infrastructure.
== Motivation
Current community management solutions on Nostr often require complex relay-specific implementations, lack proper decentralization and don't allow publications to be targeted at more than one community.
This proposal aims to simplify community management by utilizing existing Nostr primitives (key pairs and relays) while adding minimal new event kinds.
== Specification
=== Community Creation Event
A community is created when a key pair publishes a `kind:32221` event with the following structure:
[source,json]
----
{
"kind": 32221,
"content": "",
"tags": [
["relay", ""],
["relay", "", "backup"],
["relay", "", "backup"],
["blossom", ""],
["blossom", "", "backup"],
["p", "", " "],
["mint", ""],
["welcome", ""]
]
}
----
.Tag definitions
[horizontal]
relay:: URLs of relays where community content should be published. First one is considered main relay.
blossom:: URLs of blossom servers for additional community features (optional).
p:: Community role assignments. Multiple allowed. Format: `["p", "", " "]`.
mint:: URL of community mint for token/payment features (optional).
welcome:: Event ID of a welcome/introduction post (optional).
The pubkey of the key pair that creates this event serves as the unique identifier for the community. This means:
1. Each key pair can only represent one community
2. Communities can be easily discovered by querying for the most recent `kind:32221` event for a given pubkey
3. Community managers can update their settings by publishing a new `kind:32221` event
=== Community Identifier Format
Communities can be referenced using an "ncommunity" format:
----
ncommunity://?relay= &relay=
----
This format follows the same principles as nprofile, but specifically for community identification. While the ncommunity format is recommended for complete relay information, the standard pubkey format can also be used when relay discovery is not needed.
=== Targeted Publication Event
To target an existing publication at specific communities, users create a `kind:32222` event:
[source,json]
----
{
"kind": 32222,
"content": "",
"tags": [
["e", ""],
["p", ""],
["c", ""],
["r", ""]
]
}
----
The event must be found on the community's specified main relay to be considered valid. The `e` tag references the original publication event that is being targeted at the communities. Communities can be referenced either using:
* The `p` tag with the community's pubkey (for simple cases where relay discovery is not needed)
* The `c` tag with a bech32-encoded ncommunity identifier (which includes both the community pubkey and its relay information)
=== Community Chat Messages
For chat messages within a community, users should use `kind:9` events with a community tag:
[source,json]
----
{
"kind": 9,
"content": "",
"tags": [
["h", ""]
]
}
----
== Implementation Notes
1. Clients SHOULD verify that targeted publications (`kind:32222`) are present on the community's main relays. The main relay specified in the community creation event SHOULD be considered authoritative for community-related events. Clients MAY, however, fall back on a backup relay (as the authority) when the main relay is offline.
2. Clients MAY cache community metadata (`kind:30003`) events to reduce relay queries.
3. Relay operators MAY implement/automate additional filtering or moderation based on community specifications.
4. When encountering a `p` tag without corresponding relay information, clients SHOULD attempt to discover the community's relays through other means (e.g., known community relays, cached metadata).
== Benefits
1. Any existing npub can become a community
2. Communities are not permanently tied to specific relays
3. Simplified relay operator implementation compared to other community proposals
4. Supports relay-per-community model while remaining flexible
5. Enables cross-community interaction through targeted publications
6. The ability to target publications to more than one community and the access to any desired content type eliminates the need for #channels or rooms
7. Flexible referencing allows for both simple and complete community identification
== Security Considerations
1. Clients MUST verify event signatures from community managers
2. Relays SHOULD implement rate limiting for community-related events
3. Clients SHOULD respect the relay hierarchy specified in community creation events
4. When using simple pubkey references, clients should be aware of potential relay discovery challenges
== Use Case for Private Groups and DMs
The Communi-keys structure naturally extends to private groups and DMs by leveraging relay-side authentication:
=== Private Groups
* The community's profile metadata and relay address remain publicly readable
* All content (chats, posts, articles, polls, etc.) is only readable by npubs that meet the group's conditions
=== Direct Messages (DMs)
* DMs are simply a private groups of two
* The npub representing the DM "room" doesn't need public metadata
* Clients can display the room using the other participant's name
* The room's npub can be stored locally or in encrypted form elsewhere for multi-device access
* Provides a clean separation between the chat identity and the participants' identities
This approach unifies community, group, and DM management under a single model while maintaining privacy through relay-side authentication.