quoting naddr1qv…l3jwAny Nostr key pair can become a community with no special relay or infrastructure required. A single event declares the community's relays, blossom servers, and named content sections. Each section is backed by a profile list that controls publishing access.
Any existing event kind can target one or more communities via an `h` tag, making most existing publications community-aware without changing their format.
# Community Creation Event (kind:10222)
A community is created when a key pair publishes a [[nostr-community|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 [[nostr-profile|kind 0]] metadata event.
```json
{
"id": "",
"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 with this community's h tag from profile-list members
["r", "", "enforced"],
["r", ""],
// one or more blossom servers
["blossom", ""],
// one or more ecash mints
["mint", "", "cashu"],
// optional other server/infrastructure (one tag name per service type, value = URL)
["livekit", ""],
// future: other tags e.g. ["", " "] 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::Interactions", " "], // profile list
// one or more content sections for publishing
["content", "Chat"],
["k", "9"],
["a", "30000::Chat", " "], // profile list
["content", "Forum"],
["k", "11"],
["a", "30000::Forum", " "], // profile list
["content", "Apps"],
["k", "32267"], // apps
["k", "30063"], // releases
["a", "30000::Apps", " "], // profile list
// Optional terms of service, points to another event
["tos", "", " "],
// Optional location
["location", ""],
["g", ""],
// Optional language(s) — repeat for multilingual communities
["l", "en", "ISO-639-1"]
],
"content": "",
"sig": ""
}
```
## Tag definitions
| Tag | Description |
|-----|-------------|
| `r` | Relay URLs for community content. First is main relay. Optional second value `enforced`: this relay only stores events that have this community's pubkey in an `h` tag and whose author is in the relevant profile list for that event's kind; clients can trust that all such events on this relay are from list members. |
| `blossom` | Blossom server URLs. |
| `mint` | Mint URL for token/payment features. |
| `livekit` | LiveKit server URL for real-time audio/video. |
| *other* | Communities MAY use additional tags for other server-side services; tag name = service type, first value = URL. Clients SHOULD ignore unknown tags. |
| `content` | Name of content section (e.g., "Chat", "Forum"). |
| `k` | Event kind allowed in this section. |
| `a` | Profile list reference: `30000:: `. Contains member pubkeys and metadata. |
| `retention` | Retention policy: [kind, value, type]. Type is "time" (seconds) or "count". |
| `tos` | Reference to posting policy event. |
| `location` | Community location. |
| `g` | Geo hash. |
| `l` | Language tag: ISO-639-1 code (e.g. `"en"`), mark MUST be `"ISO-639-1"`. Repeat for multilingual communities. |
The `a` tag within a content section references a profile list ([[nostr-list|kind 30000]]) that contains all member pubkeys (`p` tags) who can publish to this section. The profile list also contains membership metadata (name, image) and an optional `form` tag (NIP form reference or web URL) for requesting membership. See [Profile List Metadata](#profile-list-metadata) below.
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 [[nostr-community|kind 10222]] event for a given pubkey
3. Community managers can update their settings by publishing a new [[nostr-community|kind 10222]] event
# Profile Lists
Each content section references a [[nostr-profile-list|profile list]] ([[nostr-list|kind 30000]]) that controls who can publish to that section. The `a` tag within a content section points to the list by `30000:: `. The whitelist is simply the set of `p` tags in that list — a pubkey is allowed if it appears there.
## Access Requests
A profile list MAY include a `form` tag pointing to a [[nostr-form|Form]] template (`30168:: `) or a plain web URL. This is the community's public intake channel:
1. A prospective contributor fetches the form template and submits a form response (kind:1069)
2. The community admin reviews the response and, if approved, adds the pubkey as a `p` tag to the profile list
3. That pubkey can now publish to that section — no separate approval event needed
Communities may choose to automate this flow by managing the list with an on-server hot-key that instantly adds/removes profiles based on responses.
Apps targeting a specific community may bypass the form entirely and provide their own UX; with the `form` tag as a fallback for interoperabilty.
## Multiple Tiers
Different content sections can reference different profile lists, creating natural access tiers. A community might require a separate application to publish apps while letting any approved pubkey post in chat. Each list carries its own display name, badge image, and description — see [[nostr-profile-list|Profile List]] for the full spec.
# Targeting publications at communities
Publications target communities via **one or more `h` tags** on the event. Each `h` tag value is a community pubkey. This keeps the model simple and works with replaceable events (one per kind+pubkey or kind+pubkey+d).
- **Forum** [[nostr-community|kind 11]] and **Chat** [[nostr-community|kind 9]] are exclusive to a single community: use exactly one `h` tag with that community's pubkey.
- **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
Chat messages [[nostr-community|kind 9]] and Forum posts [[nostr-community|kind 11]] are exclusive by default. They can only belong to one community and cannot be targeted to multiple communities. They use a single `h` tag to reference their community directly.
For chat messages within a community, users should use [[nostr-community|kind 9]] events with a community tag:
```json
{
"id": "",
"pubkey": "",
"created_at": 1675642635,
"kind": 9,
"tags": [
["h", ""]
],
"content": "",
"sig": ""
}
```
The same pattern applies to Forum posts, see [[nostr-community|kind 11]].
# Requesting from relays
When reading community content, request events (with the community's `h` tag) from the relays listed in the community's definition. Relays marked with `enforced` only store events from profile list members for that community, so results need no extra client-side filtering. Relays without `enforced` may store any author; the client must filter by the profile list(s) to show only list members.
# Common Content Sections
Communities can define any mix of content sections. Some sections bundle event kinds that naturally belong together. Below are standard configurations.
## Activity
Recommended for all communities. Covers all forms of activity on community content: reactions, comments, reposts, labels, and reports.
| Kind | Description |
|------|-------------|
| kind:7 | Reactions |
| kind:1111 | Comments |
| kind:6 | Reposts |
| kind:16 | Generic Reposts |
| kind:1985 | Labels |
| kind:1984 | Reports |
Reposts (kind:6, kind:16) allow community members to bring any existing publication — including content authored outside the community — into the community's feed without needing to be the original author.
Labels (kind:1985) can also function as a categorized repost: a member targets a label event at the community's relay to surface and tag external content under a community-defined category without republishing the original event or requiring authorship.
When a publication targets multiple communities, members from all those communities participate together: filter by the Activity section's profile list from each targeted community. Members meet in one shared discussion around the publication — no duplicates, no fragmented conversations across multiple places.
Communities that don't want to be part of discussions with certain other communities can simply not accept those events.
## Projects
For project planning and tracking.
| Kind | Description |
|------|-------------|
| kind:30315 | Projects |
| kind:30316 | Milestones |
## Apps
For app and release publishing.
| Kind | Description |
|------|-------------|
| kind:32267 | Apps |
| kind:30063 | Releases |
## Forum
For threaded discussion. Uses [[nostr-community|kind 11]] posts, each targeting the community via a single `h` tag. Forum posts are exclusive to one community and cannot be targeted at multiple communities simultaneously.
## Chat
For real-time messaging. Uses [[nostr-community|kind 9]] messages, each targeting the community via a single `h` tag. Chat messages are exclusive to one community and cannot be targeted at multiple communities simultaneously.
# 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 [[nostr-pin|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 [[nostr-community|kind 10222]] event to get content sections and which relays (if any) are `enforced`
2. Fetch the profile list [[nostr-list|kind 30000]] for each section to get allowed pubkeys
3. Query for events targeting the community (via `h` tag). When reading from an `enforced` relay, events are already restricted to profile list members; otherwise filter by the member pubkeys using the `authors` filter
**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
It is actually quite pleasant to work with it. Just using it for totally open stuff right now. the more private stuff might be a bit harder