From 937ed0610d596a92e941f8ee27b9cb165ba7f286 Mon Sep 17 00:00:00 2001 From: vivganes Date: Wed, 30 Aug 2023 17:36:32 +0530 Subject: [PATCH 1/6] support for community-exclusive posts --- 72.md | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++---- README.md | 1 + 2 files changed, 55 insertions(+), 4 deletions(-) diff --git a/72.md b/72.md index 599a4c4555..9e82c8b9bc 100644 --- a/72.md +++ b/72.md @@ -4,9 +4,9 @@ NIP-72 Moderated Communities (Reddit Style) ------------------------------------ -`draft` `optional` `author:vitorpamplona` `author:arthurfranca` +`draft` `optional` `author:vitorpamplona` `author:arthurfranca` `author:vivganes` -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 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. Users that want to post *exclusively* into the community send an event `kind:4549`. Moderators issue an approval event `kind:4550` that links the community with the new post. # Community Definition @@ -55,6 +55,50 @@ Any Nostr event can be a post request. Clients MUST add the community's `a` tag "content": "" } ``` +# New Post Request (Exclusive to community audience) + +When we use kind 1, the note can show up in other clients without context, creating confusion. + +To create a post exclusive to a community's audience, clients MUST use kind `4549` with the same `a` tag as above and MAY add an additional `k` tag with value `"1"` + +```json +{ + "id": "<32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>", + "pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>", + "created_at": , + "kind": 4549, + "tags": [ + ["a", "34550::", ""], + ["k", "1"] + ], + "content": "" +} +``` + +# Support for Different Event Kinds +Nostr communities are not just for kind `1` events. Clients can send any valid nostr event exclusively to a specific community's audience by wrapping the event in a `4549` kind event. + +While sending a non kind `1` event, the clients MUST populate the `content` field of the event with the _the stringified JSON of the event_. This is similar to the ones used for reposts in [NIP-18](18.md). + +Additionally, for non kind `1` events, the clients MUST add a `k` tag with value of the kind of event to be posted. + +For example, if the user wants to publish a long-form post exclusively to a community, then the post request `4549` event should contain a `k` tag with value `30023`, as defined in [NIP-23](23.md) + +Clients MAY assume any event of kind `4549` without a `k` tag to be of kind `1`. + +```json +{ + "id": "<32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>", + "pubkey": "<32-bytes lowercase hex-encoded public key of the event creator>", + "created_at": , + "kind": 4549, + "tags": [ + ["a", "34550::", ""], + ["k", ""] + ], + "content": "" +} +``` 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)). @@ -80,7 +124,12 @@ 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. +Post 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 `e`-approval 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 included in all `34550:*` `a` tags. @@ -90,12 +139,13 @@ Community clients SHOULD display posts that have been approved by at least 1 mod The following filter displays the approved posts. -```js +```json { "authors": ["", "", "", "", ...], "kinds": [4550], "#a": ["34550::"], } ``` +When the clients encounter a `kind:4549` event, they MAY treat the `content` field as the actual event, except when there is no `k` tag or when `k` has a value of `1`, in which case the clients can treat it as a kind 1 event. Clients MAY hide approvals by blocked moderators at the user's request. diff --git a/README.md b/README.md index 7951339f75..0557b62d42 100644 --- a/README.md +++ b/README.md @@ -92,6 +92,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos | `1311` | Live Chat Message | [53](53.md) | | `1984` | Reporting | [56](56.md) | | `1985` | Label | [32](32.md) | +| `4549` | Community Exclusive Post | [72](72.md) | | `4550` | Community Post Approval | [72](72.md) | | `9734` | Zap Request | [57](57.md) | | `9735` | Zap | [57](57.md) | From 233766921b532f6c031fd1ed0f4e94f56c720bab Mon Sep 17 00:00:00 2001 From: Vivek Ganesan Date: Sat, 2 Sep 2023 10:30:06 +0530 Subject: [PATCH 2/6] Update 72.md Co-authored-by: arthurfranca --- 72.md | 1 - 1 file changed, 1 deletion(-) diff --git a/72.md b/72.md index 9e82c8b9bc..e006fc3adb 100644 --- a/72.md +++ b/72.md @@ -78,7 +78,6 @@ To create a post exclusive to a community's audience, clients MUST use kind `454 # Support for Different Event Kinds Nostr communities are not just for kind `1` events. Clients can send any valid nostr event exclusively to a specific community's audience by wrapping the event in a `4549` kind event. -While sending a non kind `1` event, the clients MUST populate the `content` field of the event with the _the stringified JSON of the event_. This is similar to the ones used for reposts in [NIP-18](18.md). Additionally, for non kind `1` events, the clients MUST add a `k` tag with value of the kind of event to be posted. From a6ef65d917235388f16937f1aa641057822c4b6a Mon Sep 17 00:00:00 2001 From: Vivek Ganesan Date: Sat, 2 Sep 2023 10:30:36 +0530 Subject: [PATCH 3/6] Update 72.md Co-authored-by: arthurfranca --- 72.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/72.md b/72.md index e006fc3adb..c26621d31d 100644 --- a/72.md +++ b/72.md @@ -79,7 +79,7 @@ To create a post exclusive to a community's audience, clients MUST use kind `454 Nostr communities are not just for kind `1` events. Clients can send any valid nostr event exclusively to a specific community's audience by wrapping the event in a `4549` kind event. -Additionally, for non kind `1` events, the clients MUST add a `k` tag with value of the kind of event to be posted. +Additionally, the clients MUST add a `k` tag with value of the kind of event to be posted. For example, if the user wants to publish a long-form post exclusively to a community, then the post request `4549` event should contain a `k` tag with value `30023`, as defined in [NIP-23](23.md) From 654285a297bc86f205af34ed432b0be1652fb5da Mon Sep 17 00:00:00 2001 From: Vivek Ganesan Date: Sat, 2 Sep 2023 10:31:02 +0530 Subject: [PATCH 4/6] Update 72.md Co-authored-by: arthurfranca --- 72.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/72.md b/72.md index c26621d31d..c37acf1ec2 100644 --- a/72.md +++ b/72.md @@ -69,7 +69,7 @@ To create a post exclusive to a community's audience, clients MUST use kind `454 "kind": 4549, "tags": [ ["a", "34550::", ""], - ["k", "1"] + ["k", "1"] ], "content": "" } From a73699c54b1602b2cf988195e33201d12dcca779 Mon Sep 17 00:00:00 2001 From: Vivek Ganesan Date: Sat, 2 Sep 2023 10:31:12 +0530 Subject: [PATCH 5/6] Update 72.md Co-authored-by: arthurfranca --- 72.md | 1 - 1 file changed, 1 deletion(-) diff --git a/72.md b/72.md index c37acf1ec2..9a8d1bd954 100644 --- a/72.md +++ b/72.md @@ -145,6 +145,5 @@ The following filter displays the approved posts. "#a": ["34550::"], } ``` -When the clients encounter a `kind:4549` event, they MAY treat the `content` field as the actual event, except when there is no `k` tag or when `k` has a value of `1`, in which case the clients can treat it as a kind 1 event. Clients MAY hide approvals by blocked moderators at the user's request. From c1fc24d570817afbe814d99343b54bc134997f4e Mon Sep 17 00:00:00 2001 From: vivganes Date: Sat, 2 Sep 2023 10:42:09 +0530 Subject: [PATCH 6/6] fix review comments --- 72.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/72.md b/72.md index 9a8d1bd954..3aeba4bec0 100644 --- a/72.md +++ b/72.md @@ -59,7 +59,7 @@ Any Nostr event can be a post request. Clients MUST add the community's `a` tag When we use kind 1, the note can show up in other clients without context, creating confusion. -To create a post exclusive to a community's audience, clients MUST use kind `4549` with the same `a` tag as above and MAY add an additional `k` tag with value `"1"` +To create a kind 1 post exclusive to a community's audience, clients MUST use kind `4549` with the same `a` tag as above and MAY add an additional `k` tag with value `"1"` ```json { @@ -78,10 +78,9 @@ To create a post exclusive to a community's audience, clients MUST use kind `454 # Support for Different Event Kinds Nostr communities are not just for kind `1` events. Clients can send any valid nostr event exclusively to a specific community's audience by wrapping the event in a `4549` kind event. - Additionally, the clients MUST add a `k` tag with value of the kind of event to be posted. -For example, if the user wants to publish a long-form post exclusively to a community, then the post request `4549` event should contain a `k` tag with value `30023`, as defined in [NIP-23](23.md) +For example, if the user wants to publish a long-form post exclusively to a community, then the post request `kind:4549` event should contain a `k` tag with value `30023`, while retaining the same `content` as if creating a long-form post as defined in [NIP-23](23.md) Clients MAY assume any event of kind `4549` without a `k` tag to be of kind `1`. @@ -93,9 +92,9 @@ Clients MAY assume any event of kind `4549` without a `k` tag to be of kind `1`. "kind": 4549, "tags": [ ["a", "34550::", ""], - ["k", ""] + ["k", ""] ], - "content": "" + "content": "" } ```