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
    // optional "enforced" = relay only stores events from authors allowed by the section's lists (kind 9 in a room: community in `c`, see [Room][nostr-room])
    ["r", "<relay-url>", "enforced"],
    ["r", "<relay-url>"],
    // one or more blossom servers
    ["blossom", "<blossom-url>"],

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

    // future: other tags e.g. ["<service-type>", "<url>"] as needed

    // Interactions section for comments, reactions, and labels (recommended for all communities)
    ["content", "Interactions"],
    ["k", "1111"], // comments
    ["k", "7"],    // reactions
    ["k", "1985"], // labels
    ["a", "30000:<pubkey>:Interactions", "<relay-url>"], // profile list

    // Rooms: room definitions (kind 30223) — no `a` on this row; per-room lists live on each 30223 ([Room][nostr-room]). Chat in rooms is still kind 9.
    ["content", "Rooms"],
    ["k", "30223"],

    ["content", "Forum"],
    ["k", "11"],
    ["a", "30000:<pubkey>:Forum", "<relay-url>"], // profile list

    ["content", "Apps"],
    ["k", "32267"], // apps
    ["k", "30063"], // releases
    ["a", "30000:<pubkey>:Apps", "<relay-url>"], // profile list

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

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

    // Optional language(s) — repeat for multilingual communities
    ["l", "en", "ISO-639-1"]
  ],
  "content": "",
  "sig": "<signature>"
}

Profile Lists

Each content section references a profile list via a, except Rooms — Rooms. The whitelist is the set of p tags on the fetched list.

Rooms

On 10222, Rooms is declared with content + k 30223 (room definitions), no a. Chat in those rooms is still kind 9 with c = community pubkey and h = opaque room id (NIP-29 group id shape — not the display name); see Room. ACL for posting is only on each 30223. Clients MUST ignore any a on the Rooms block. Enforcing relays MAY bucket kind 9 by #h like NIP-29; scope with #c.

Targeting publications at communities

Most publications target communities via one or more h tags; each value is a community pubkey. Exception — Room kind 9: c = community pubkey, h = opaque room id (Room).

• Forum kind 11 is exclusive to one community: exactly one h = community pubkey.
• Kind 9 in a room (Room): exactly one c = community pubkey and one h = room id; see Rooms.
• Other publications (e.g. kind 32267, articles, etc.) may use multiple h tags to target several communities simultaneously; clients filter by these tags when listing content.
• Comments, reactions, and zaps carry no h tag of their own — they just reference the h-tagged event they interact with.

Anyone can zap community content regardless of whitelist status. Query zap receipts on the community relays with no author filtering — external appreciation is always welcome.

Community-Exclusive Publications

Kind 9 (in a room) and Forum kind 11 are exclusive to one community. Forum: h = community pubkey. Kind 9 in a room: c = community pubkey, h = opaque room id (Room, Rooms).

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

Forum posts are defined in kind 11.

Requesting from relays

When reading community content, query the community’s relays. For most kinds, filter by #h = community pubkey; for kind 9 in a room, #c = community pubkey and #h = room id (Room). Relays marked enforced only store events from allowed authors per the relevant lists. Relays without enforced may store any author; clients filter by membership.

Common Content Sections

Communities can define any mix of content sections. Typical bundles are below; Rooms (k 30223 on 10222) is in Rooms.

Listing a User’s Communities

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

Pinned Content

Communities can also publish a kind 10001 pin list like any other profile. This gives communities a built-in way to feature content — pinned articles, apps, releases, or any other event — without any additional spec. Clients that display pinned events on profiles will automatically show them for communities too.

Implementation Notes

Communities work on any standard Nostr relay. Access control may be enforced client-side only, or optionally by relays that the community marks with enforced on the r tag.

Client filtering workflow:

1. Fetch the community’s kind 10222 event to get content sections and which relays (if any) are enforced
2. Fetch lists: each section’s a tags, except Rooms (no a on 10222 — use 30223, Rooms)
3. Query: #h = community for most kinds; kind 9 in a room uses #c = community and #h = room id (Room). With enforced, lists are already applied; otherwise filter authors against the right lists.

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 profile lists to reduce relay queries
• Clients SHOULD check membership before attempting to publish
• Relays MAY optionally enforce profile list membership (and then list themselves with enforced in the community’s r tag); otherwise clients filter by membership. Relays MAY implement retention policies; this is not required.

Benefits

1. No special relay required — works on any standard Nostr relay
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. Most existing publications 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 membership-based access control
7. Cross-community interaction via multi-community h tags on publications
8. Users can request access by submitting Form Responses
9. Simple membership management — just add/remove p tags in the membership list