NIP-72
Moderated Communities (Reddit Style)
draft unrecommended
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
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:
- By tagging the replaceable event as an
etag if moderators want to approve each individual change to the replaceable event - By tagging the replaceable event as an
atag if the moderator authorizes the replaceable event author to make changes without additional approvals and - By tagging the replaceable event with both its
eandatag 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.