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.

Community Creation Event (kind:10222)

A community is created when a key pair publishes a kind-10222 event. The pubkey of this key pair becomes the unique identifier for that community. One key pair can only represent one community.

The community’s name, picture, and description are derived from the pubkey’s kind-0 metadata event.

{
  "id": "<event-id>",
  "pubkey": "<community-pubkey>",
  "created_at": 1675642635,
  "kind": 10222,
  "tags": [
    // at least one main relay for the community + other optional backup relays
    ["r", "<relay-url>"],

    // one or more blossom servers
    ["blossom", "<blossom-url>"],

    // one or more ecash mints
    ["mint", "<mint-url>", "cashu"],

    // one or more content sections: ["content", "<name>"]
    ["content", "Chat"],
    ["k", "9"],
    ["a", "<badge-definition>"], // only npubs with this badge can publish Chat messages

    ["content", "Posts"],
    ["k", "1"],
    ["k", "11"],
    ["a", "<badge-definition>"], // only npubs with this badge can publish Posts

    ["content", "Articles"],
    ["k", "30023"],
    ["k", "30040"],
    ["a", "<badge-definition-member>"],
    ["a", "<badge-definition-pro>"],
    ["a", "<badge-definition-team>"], // users with any of these badges can publish Articles

    // Optional terms of service, points to another event
    ["tos", "<event-id-or-address>", "<relay-url>"],

    // Optional location
    ["location", "<location>"],
    ["g", "<geo-hash>"],

    // Optional description
    ["description", "A description text that overwrites the profile's description, if needed"]
  ],
  "content": "",
  "sig": "<signature>"
}

Community Identifier Format

Communities can be referenced using an “ncommunity” format:

ncommunity://<pubkey>?relay=<url-encoded-relay-1>&relay=<url-encoded-relay-2>

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.

Listing a User’s Communities

Since communities are just pubkeys, existing Nostr primitives can be used to list which communities a user is part of.

Targeted Publication Event (kind:30222)

To target an existing publication at specific communities, users create a kind-30222 event:

{
  "id": "<event-id>",
  "pubkey": "<pubkey>",
  "created_at": 1675642635,
  "kind": 30222,
  "tags": [
    ["d", "<random-id>"],
    ["e", "<event-id-of-original-publication>"],
    ["k", "<kind-of-original-publication>"],
    ["p", "<community1-pubkey>"],
    ["r", "<main-relay1-url>"],
    ["p", "<community2-pubkey>"],
    ["r", "<main-relay2-url>"]
  ],
  "content": "",
  "sig": "<signature>"
}

The targeted publication event can reference the original publication in two ways:

1. Using an e tag with the event ID, relay hint, and pubkey hint
2. Using an a tag with the event address and relay hint

The k tag specifies the kind of the original publication, and the p tags list the communities that this publication is targeting.

Currently, we work with a maximum of 12 communities that can be tagged for one publication.

Note: For publishing new events, clients SHOULD create a targeted Publication event first (that only has an id) and reference it with an h tag in the main event.

Community-Exclusive Publications

Chat messages kind-9 and Forum posts kind-11 are exclusive by default. They can only belong to one community and cannot be targeted to multiple communities.

For these exclusive content types, we don’t need a Targeted Publication event. Instead, they use an h tag to reference their community directly.

For chat messages within a community, users should use kind-9 events with a community tag:

{
  "id": "<event-id>",
  "pubkey": "<pubkey>",
  "created_at": 1675642635,
  "kind": 9,
  "tags": [
    ["h", "<community-pubkey>"]
  ],
  "content": "<message>",
  "sig": "<signature>"
}

The same pattern applies to Forum posts, see kind-11.

Badge-Based Access Control

Communities use Badges for publishing permissions. Each content section can have one or more a tags referencing Badge Definitions. Users holding any of these badges can publish to that content section.

["content", "Articles"],
["k", "30023"],
["a", "30009:community-pubkey:member"],
["a", "30009:community-pubkey:pro"],
["a", "30009:community-pubkey:team"]

In this example, “Member”, “Pro”, and “Team” badge holders can all publish Articles.

Badge Definitions can include a form tag that references a Form Template, see kind-30168 and NIP-101. Users request badges by submitting a Form Response kind-1069 that references both the form and the badge. This allows communities to collect information from users before granting access.

Comments, Reactions, Labels, and Zaps

When a publication targets multiple communities, members from all those communities participate together:

Comments, reactions, and labels — filter by badgeholder pubkeys from all targeted communities. Members from different communities meet in one shared discussion around the publication. No duplicates, no fragmented conversations across multiple places.

NOTE: Communities that don’t want to be part of disocussoons with certain other communities can just not accept the evnts regarding them.

Zaps — anyone can zap community content. Query zap receipts on the community relays. No badgeholder filtering — external appreciation is always welcome.

Implementation Notes

Unlike NIP-29 (Relay-based Groups), Communikeys work on any standard Nostr relay. Access control is enforced client-side, not by relays (although they can of course optimize for it).

Client filtering workflow:

1. Fetch the community’s kind-10222 event to get content sections and their k tags
2. Query for events of those kinds targeting the community (via h tag or Targeted Publication)
3. Filter results to only show events from pubkeys holding any of the required badges for that content section

Media fallback:

Community blossom servers SHOULD back up all media files referenced in community publications — even when the original URLs point to different servers. By storing files by their content hash, the community server becomes a reliable fallback when external URLs suffer link rot. Clients can try the community’s blossom server when the original media URL fails.

Additional recommendations:

• Clients MAY cache community metadata and badge awards to reduce relay queries
• Clients SHOULD check badge requirements before attempting to publish
• Relays MAY optionally verify badge requirements or implement retention policies, but this is not required

Benefits

1. No special relay required — works on any standard Nostr relay, unlike NIP-29
2. Easy onboarding — new users don’t need to set up any personal relay or media server to join Nostr via a community. They can use the community’s relay and blossom server immediately.
3. Any existing npub can become a community
4. Any existing publication can be targeted at communities (backwards compatible)
5. Communities are not permanently tied to specific relays
6. Communities can define their own content types with badge-based access control
7. Cross-community interaction via Targeted Publications
8. Users can request access by submitting Form Responses
9. Delegated badge awarding — separate keys can handle membership without exposing the main community keypair