Moderated Communities

The goal of this NIP is to enable public communities. It defines the replaceable event kind:34550 to define the community and the current list of moderators/administrators. Users that want to post into the community, simply tag any Nostr event with the community's a tag. Moderators may issue an approval event kind:4550.

Community Definition

Kind:34550 SHOULD include any field that helps define the community and the set of moderators. relay tags MAY be used to describe the preferred relay to download requests and approvals. A community definition event's d tag MAY double as its name, but if a name tag is provided, it SHOULD be displayed instead of the d tag.

{
  "created_at": <Unix timestamp in seconds>,
  "kind": 34550,
  "tags": [
    ["d", "<community-d-identifier>"],
    ["name", "<Community name>"],
    ["description", "<Community description>"],
    ["image", "<Community image url>", "<Width>x<Height>"],

    //.. other tags relevant to defining the community

    // moderators
    ["p", "<32-bytes hex of a pubkey1>", "<optional recommended relay URL>", "moderator"],
    ["p", "<32-bytes hex of a pubkey2>", "<optional recommended relay URL>", "moderator"],
    ["p", "<32-bytes hex of a pubkey3>", "<optional recommended relay URL>", "moderator"],

    // relays used by the community (w/optional marker)
    ["relay", "<relay hosting author kind 0>", "author"],
    ["relay", "<relay where to send and receive requests>", "requests"],
    ["relay", "<relay where to send and receive approvals>", "approvals"],
    ["relay", "<relay where to post requests to and fetch approvals from>"]
  ],
  // other fields...
}

Posting to a community

NIP-22 kind 1111 events SHOULD be used for text notes posted to a community, with the A tag always scoped to the community definition.

Top-level posts

For top-level posts, the uppercase and lowercase NIP-22 tags should both refer to the community definition itself.

{
  "kind": 1111,
  "tags": [
    ["A", "34550:<community-author-pubkey>:<community-d-identifier>", "<optional-relay-url>"],
    ["a", "34550:<community-author-pubkey>:<community-d-identifier>", "<optional-relay-url>"],
    ["P", "<community-author-pubkey>", "<optional-relay-url>"],
    ["p", "<community-author-pubkey>", "<optional-relay-url>"],
    ["K", "34550"],
    ["k", "34550"],
  ],
  "content": "Hi everyone. It's great to be here!",
  // other fields...
}

Nested replies

For nested replies, the uppercase tags should still refer to the community definition, while the lowercase tags should refer to the parent post or reply.

{
  "kind": 1111,
  "tags": [
    // community definition itself
    ["A", "34550:<community-author-pubkey>:<community-d-identifier>", "<optional-relay-url>"],
    ["P", "<community-author-pubkey>", "<optional-relay-url>"],
    ["K", "34550"],

    // parent post or reply
    ["e", "<parent-event-id>", "<optional-relay-url>"],
    ["p", "<parent-event-author-pubkey>", "<optional-relay-url>"],
    ["k", "<parent-event-kind>"] // most likely "1111"
  ],
  "content": "Agreed! Welcome everyone!",
  // other fields...
}

Backwards compatibility note

Previously kind 1 events were used for posts in communities, with an "a" tag pointing to the community. For backwards compatibility, clients MAY still query for kind 1 events, but SHOULD NOT use them for new posts. Instead, clients SHOULD use kind 1111 events with the A and a tags as described above.

Moderation

Anyone may issue an approval event to express their opinion that a post is appropriate for a community. Clients MAY choose which approval events to honor, but SHOULD at least use ones published by the group's defined moderators.

An approval event MUST include one or more community a tags, an e or a tag pointing to the post, and the p tag of the author of the post (for approval notifications). a tag prefixes can be used to disambiguate between community and replaceable event pointers (community a tags always begin with 34550).

The event SHOULD also include the JSON-stringified post request event inside the .content, and a k tag with the original post's event kind to allow filtering of approved posts by kind.

Moderators MAY request deletion of their approval of a post at any time using NIP-09 event deletion requests.

{
  "pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>",
  "kind": 4550,
  "tags": [
    ["a", "34550:<event-author-pubkey>:<community-d-identifier>", "<optional-relay-url>"],
    ["e", "<post-id>", "<optional-relay-url>"],
    ["p", "<port-author-pubkey>", "<optional-relay-url>"],
    ["k", "<post-request-kind>"]
  ],
  "content": "<the full approved event, JSON-encoded>",
  // other fields...
}

It's recommended that multiple moderators approve posts to avoid deleting them from the community when a moderator is removed from the owner's list. In case the full list of moderators must be rotated, the new moderator set must sign new approvals for posts in the past or the community will restart. The owner can also periodically copy and re-sign of each moderator's approval events to make sure posts don't disappear with moderators.

Approvals of replaceable events can be created in three ways:

1. By tagging the replaceable event as an e tag if moderators want to approve each individual change to the replaceable event
2. By tagging the replaceable event as an a tag if the moderator authorizes the replaceable event author to make changes without additional approvals and
3. By tagging the replaceable event with both its e and a tag which empowers clients to display the original and updated versions of the event, with appropriate remarks in the UI.

Since relays are instructed to delete old versions of a replaceable event, the content of an approval using an e tag MUST have the specific version of the event or clients might not be able to find that version of the content anywhere.

Clients SHOULD evaluate any non-34550:* a tag as posts to be approved for all 34550:* a tags.

Cross-posting

Clients MAY support cross-posting between communities by posting a NIP 18 kind 6 or kind 16 repost to one or more communities using a tags as described above. The content of the repost MUST be the original event, not the approval event.