NIP-72 - Moderated Communities (Reddit Style)
Table of Contents
Moderated Communities (Reddit Style)
draft
optional
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
Any Nostr event can be posted to a community. Clients MUST add one or more community a
tags, each with a recommended relay.
{
"kind": 1,
"tags": [
["a", "34550:<community event author pubkey>:<community-d-identifier>", "<optional-relay-url>"],
],
"content": "hello world",
// other fields...
}
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:
- By tagging the replaceable event as an
e
tag if moderators want to approve each individual change to the replaceable event - By tagging the replaceable event as an
a
tag if the moderator authorizes the replaceable event author to make changes without additional approvals and - By tagging the replaceable event with both its
e
anda
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.