upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
path: root/72.md
diff options
context:
space:
mode:
authorhodlbod <jstaab@protonmail.com>2024-07-30 15:34:51 -0500
committerGitHub <noreply@github.com>2024-07-30 15:34:51 -0500
commit40a5a83f6f54ab9ff34bcb490a0d1a9c8a23965e (patch)
tree0d7cd5f7668a3f12ba29ae66a8adf41a7ffaafec /72.md
parent289b415186b3739d72cd4c5e188874756685c01a (diff)
parentcb29f752e87446119ea6a5f066c6be352d8b87ca (diff)
Merge pull request #1024 from coracle-social/nip-72-edits
Nip 72 edits
Diffstat (limited to '72.md')
-rw-r--r--72.md45
1 files changed, 20 insertions, 25 deletions
diff --git a/72.md b/72.md
index 5a8be0a..d19b80b 100644
--- a/72.md
+++ b/72.md
@@ -6,11 +6,11 @@ Moderated Communities (Reddit Style)
6 6
7`draft` `optional` 7`draft` `optional`
8 8
9The 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. 9The 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`.
10 10
11# Community Definition 11# Community Definition
12 12
13`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. 13`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.
14 14
15```jsonc 15```jsonc
16{ 16{
@@ -18,6 +18,7 @@ The goal of this NIP is to create moderator-approved public communities around a
18 "kind": 34550, 18 "kind": 34550,
19 "tags": [ 19 "tags": [
20 ["d", "<community-d-identifier>"], 20 ["d", "<community-d-identifier>"],
21 ["name", "<Community name>"],
21 ["description", "<Community description>"], 22 ["description", "<Community description>"],
22 ["image", "<Community image url>", "<Width>x<Height>"], 23 ["image", "<Community image url>", "<Width>x<Height>"],
23 24
@@ -38,9 +39,9 @@ The goal of this NIP is to create moderator-approved public communities around a
38} 39}
39``` 40```
40 41
41# New Post Request 42# Posting to a community
42 43
43Any 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. 44Any Nostr event can be posted to a community. Clients MUST add one or more community `a` tags, each with a recommended relay.
44 45
45```jsonc 46```jsonc
46{ 47{
@@ -53,11 +54,15 @@ Any Nostr event can be submitted to a community by anyone for approval. Clients
53} 54}
54``` 55```
55 56
56Community 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)). 57# Moderation
57 58
58# Post Approval by moderators 59Anyone 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.
59 60
60The 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. 61An 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`).
62
63The 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.
64
65Moderators MAY delete their approval of a post at any time using NIP 09 event deletions.
61 66
62```jsonc 67```jsonc
63{ 68{
@@ -76,26 +81,16 @@ The post-approval event MUST include `a` tags of the communities the moderator i
76 81
77It'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. 82It'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.
78 83
79Post 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 replaceable 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. 84Approvals of replaceable events can be created in three ways:
80 85
81Clients SHOULD evaluate any non-`34550:*` `a` tag as posts to be included in all `34550:*` `a` tags. 861. By tagging the replaceable event as an `e` tag if moderators want to approve each individual change to the replaceable event
872. By tagging the replaceable event as an `a` tag if the moderator authorizes the replaceable event author to make changes without additional approvals and
883. 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.
82 89
83# Displaying 90Since 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.
84 91
85Community clients SHOULD display posts that have been approved by at least 1 moderator or by the community owner. 92Clients SHOULD evaluate any non-`34550:*` `a` tag as posts to be approved for all `34550:*` `a` tags.
86 93
87The following filter displays the approved posts. 94# Cross-posting
88
89```json
90[
91 "REQ",
92 "_",
93 {
94 "authors": ["<owner-pubkey>", "<moderator1-pubkey>", "<moderator2-pubkey>", "<moderator3-pubkey>", ...],
95 "kinds": [4550],
96 "#a": ["34550:<Community event author pubkey>:<d-identifier of the community>"],
97 }
98]
99```
100 95
101Clients MAY hide approvals by blocked moderators at the user's request. 96Clients 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.