From 0ff2fa3212ca66e3f7177da431084d4fde9386cd Mon Sep 17 00:00:00 2001 From: Jon Staab Date: Mon, 8 Jan 2024 09:53:23 -0800 Subject: [PATCH 1/3] Add title to NIP 72, mention cross-posting and clarify moderation options --- 72.md | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-) diff --git a/72.md b/72.md index 4bafce0..968a9ed 100644 --- a/72.md +++ b/72.md @@ -10,7 +10,7 @@ The goal of this NIP is to create moderator-approved public communities around a # 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. +`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. ```jsonc { @@ -18,6 +18,7 @@ The goal of this NIP is to create moderator-approved public communities around a "kind": 34550, "tags": [ ["d", ""], + ["name", ""], ["description", ""], ["image", "", "x"], @@ -38,9 +39,9 @@ The goal of this NIP is to create moderator-approved public communities around a } ``` -# New Post Request +# Community Posts -Any Nostr event can be submitted to a community by anyone for approval. Clients MUST add the community's `a` tag to the new post event in order to be presented for the moderator's approval. +Any Nostr event can be posted to a community. Clients MUST add one or more community `a` tags, each with a recommended relay. ```jsonc { @@ -53,11 +54,13 @@ Any Nostr event can be submitted to a community by anyone for approval. Clients } ``` -Community management clients MAY filter all mentions to a given `kind:34550` event and request moderators to approve each submission. Moderators MAY delete his/her approval of a post at any time using event deletions (See [NIP-09](09.md)). +# Moderation -# Post Approval by 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 post-approval event MUST include `a` tags of the communities the moderator is posting into (one or more), the `e` tag of the post and `p` tag of the author of the post (for approval notifications). The event SHOULD also include the stringified `post request` event inside the `.content` ([NIP-18-style](18.md)) and a `k` tag with the original post's event kind to allow filtering of approved posts by kind. +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 delete their approval of a post at any time using NIP 09 event deletions. ```jsonc { @@ -76,13 +79,21 @@ The post-approval event MUST include `a` tags of the communities the moderator i 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. -Post Approvals of replaceable events can be created in three ways: (i) by tagging the replaceable event as an `e` tag if moderators want to approve each individual change to the repleceable event; (ii) by tagging the replaceable event as an `a` tag if the moderator authorizes the replaceable event author to make changes without additional approvals and (iii) 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 `e`-approval MUST have the specific version of the event or Clients might not be able to find that version of the content anywhere. +Approvals of replaceable events can be created in three ways: -Clients SHOULD evaluate any non-`34550:*` `a` tag as posts to be included in all `34550:*` `a` tags. +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. + +# 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. # Displaying -Community clients SHOULD display posts that have been approved by at least 1 moderator or by the community owner. +Clients SHOULD display posts that have been approved by at least 1 moderator or by the community owner. Clients MAY disregard moderation and fetch community posts directly. The following filter displays the approved posts. From 42932deb0a9265de0b668e3f34a418177c1b8d2f Mon Sep 17 00:00:00 2001 From: Jon Staab Date: Mon, 5 Feb 2024 09:26:14 -0800 Subject: [PATCH 2/3] Do more to clarify moderation --- 72.md | 26 ++++---------------------- 1 file changed, 4 insertions(+), 22 deletions(-) diff --git a/72.md b/72.md index 968a9ed..cb1db22 100644 --- a/72.md +++ b/72.md @@ -6,7 +6,7 @@ Moderated Communities (Reddit Style) `draft` `optional` -The goal of this NIP is to create moderator-approved public communities around a topic. 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 issue an approval event `kind:4550` that links the community with the new post. +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 @@ -39,7 +39,7 @@ The goal of this NIP is to create moderator-approved public communities around a } ``` -# Community Posts +# 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. @@ -56,6 +56,8 @@ Any Nostr event can be posted to a community. Clients MUST add one or more commu # 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. @@ -90,23 +92,3 @@ Since relays are instructed to delete old versions of a replaceable event, the ` # 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. - -# Displaying - -Clients SHOULD display posts that have been approved by at least 1 moderator or by the community owner. Clients MAY disregard moderation and fetch community posts directly. - -The following filter displays the approved posts. - -```json -[ - "REQ", - "_", - { - "authors": ["", "", "", "", ...], - "kinds": [4550], - "#a": ["34550::"], - } -] -``` - -Clients MAY hide approvals by blocked moderators at the user's request. From 1dc8d1857172d74e81097f34f1f5c58bcc29ac51 Mon Sep 17 00:00:00 2001 From: Jon Staab Date: Thu, 30 May 2024 12:24:58 -0700 Subject: [PATCH 3/3] Fix conflicts --- 72.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/72.md b/72.md index cb1db22..d19b80b 100644 --- a/72.md +++ b/72.md @@ -89,6 +89,8 @@ Approvals of replaceable events can be created in three ways: 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.