NIP-72 improvements #1
Conversation
WalkthroughThe document was updated to expand and clarify the moderation and membership model for public communities. New event kinds were introduced for post removals, user join and leave requests, and lists of approved, declined, and banned pubkeys. Existing approval event structures were refined, and the role of moderators was further specified. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Moderator
participant Community
User->>Community: Submit join request (4552)
Community->>Moderator: Notify of join request
Moderator->>Community: Approve or decline pubkey (14550/14551/14552)
User->>Community: Submit post
Moderator->>Community: Approve post (4550) or Remove post (4551)
User->>Community: Leave request (4553)
Poem
Note ⚡️ AI Code Reviews for VS Code, Cursor, WindsurfCodeRabbit now has a plugin for VS Code, Cursor and Windsurf. This brings AI code reviews directly in the code editor. Each commit is reviewed immediately, finding bugs before the PR is raised. Seamless context handoff to your AI code agent ensures that you can easily incorporate review feedback. Note ⚡️ Faster reviews with cachingCodeRabbit now supports caching for code and dependencies, helping speed up reviews. This means quicker feedback, reduced wait times, and a smoother review experience overall. Cached data is encrypted and stored securely. This feature will be automatically enabled for all accounts on May 16th. To opt out, configure 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (6)
72.md (6)
9-9: Clarify overview grammar and phrasing
The sentence mixes a restrictive clause and an independent clause—removing the comma and using “Users who” improves readability.-Users that want to post into the community, simply tag any Nostr event with the community's `a` tag. +Users who want to post into the community should simply tag any Nostr event with the community’s `a` tag.
72-78: Suggest refining approval event snippet
Consider ordering tags by logical flow—communitya, targete/a, authorp, then optionalk—and add an example usingainstead ofefor replaceable events. This will help readers understand both cases.- "tags": [ - ["a", "34550:alice:community-d", "relay1"], - ["e", "post-id", "relay2"], - ["p", "bob", "relay2"], - ["k", "1"] - ] + "tags": [ + // community context + ["a", "34550:alice:community-d", "relay1"], + // target event: use "e" for standard or "a" for replaceable events + ["e", "post-id", "relay2"], + // post author + ["p", "bob", "relay2"], + // optional original kind + ["k", "1"] + ]
87-93: Document the removalreasonfield in narrative
The snippet introduces a top-level"reason"property but the prose doesn’t explain it. Please add a sentence before the code block such as:Removal events MAY include a
reasonproperty containing a short free-text explanation for the deletion.
This ensures readers understand how to populate and use"reason".Also applies to: 96-100
105-114: Clarify join request content semantics
The narrative notes an optional join reason but the snippet only shows"content". Explicitly state that the"content"field is reserved for the join reason (plain text) or left empty if none.
116-116: Fix grammar in leave request description
There’s an extra “is” and a word-order issue.-Users MAY request to leave a group at any time. This is does not require approval and should be always honored. +Users MAY request to leave a group at any time. This does not require approval and should always be honored.🧰 Tools
🪛 LanguageTool
[uncategorized] ~116-~116: These words/punctuation marks might seem a little out of order. For clarity and coherence, try switching them around.
Context: ...is does not require approval and should be always honored. ```jsonc { "pubkey": "<32-...(AI_EN_LECTOR_REPLACEMENT_WORD_ORDER)
150-150: Avoid repetitive sentence start
The phrase “Moderators may also maintain…” is used three times in succession. Consider rewording one instance for variety, e.g.:-Moderators may also maintain a list of declined pubkeys: users who requested to join but were not approved. +To record membership denials, moderators can publish a `14551` event listing declined pubkeys.🧰 Tools
🪛 LanguageTool
[style] ~150-~150: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ntent": "", // other fields... } ``` Moderators may also maintain a list of declined pu...(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge Base: Disabled due to data retention organization setting
📒 Files selected for processing (1)
72.md(3 hunks)
🧰 Additional context used
🪛 LanguageTool
72.md
[uncategorized] ~116-~116: These words/punctuation marks might seem a little out of order. For clarity and coherence, try switching them around.
Context: ...is does not require approval and should be always honored. ```jsonc { "pubkey": "<32-...
(AI_EN_LECTOR_REPLACEMENT_WORD_ORDER)
[style] ~150-~150: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ntent": "", // other fields... } ``` Moderators may also maintain a list of declined pu...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
🔇 Additional comments (4)
72.md (4)
63-63: Approve extended approval event description
The addition clarifies that approval events can embed the original post request and tag its kind for client-side filtering. This aligns well with the updated moderation model.
119-128: Approve leave request event structure
The leave request event correctly uses the communityatag and repurposescontentfor the leave reason. It matches the join request pattern.
136-149: Approve approved-pubkeys list event
The approved-pubkeys event clearly defines the community context and multipleptags. Structure and placeholders are consistent with the other list events.
154-164:⚠️ Potential issueCorrect placeholder for declined-pubkeys list
The snippet reuses<approved-pubkey>as the placeholder in the declined list. This is confusing—rename it to<declined-pubkey>to match intent:- ["p", "<approved-pubkey>", "<optional-relay-url>"], + ["p", "<declined-pubkey>", "<optional-relay-url>"],Likely an incorrect or invalid review comment.
| Likewise, anyone can issue a removal event to express their opinion that a post is NOT appropriate for a community. Clients MAY choose removal events to honor, but SHOULD at least use ones published by the group's defined moderators. | ||
|
|
There was a problem hiding this comment.
Fix duplicated filtering description for removal events
The copy-pasted line still refers to “approved posts,” which is misleading in the removal context. It should reference removal events instead.
-The event MAY 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.
+The event MAY 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 removal events by kind.Also applies to: 83-85
🤖 Prompt for AI Agents
In file 72.md around lines 80 to 85, the description for removal events
incorrectly references "approved posts," which is misleading. Update the text to
correctly refer to removal events instead of approved posts to accurately
reflect the context of filtering for removal events.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
72.md (1)
84-85: Fix duplicated filtering description for removal events
The copy-pasted line still refers to “approved posts,” which is misleading in the removal context. It should reference removal events instead.-The event MAY 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. +The event MAY 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 removal events by kind.This echoes a previous review on the outdated commit.
🧹 Nitpick comments (2)
72.md (2)
9-9: Refine wording to avoid repetition
The phrase “defines the replaceable event kind34550to define” repeats “define.” Consider tightening for clarity:- It defines the replaceable event kind `34550` to define the community and the current list of moderators. + It uses replaceable event kind `34550` to specify the community and its current list of moderators.
169-169: Fix grammar and possessive
Correct “who’s” and add the missing “be” for proper grammar:- Moderators may also maintain a list of banned pubkeys: users who's posts or requests should not approved. + Moderators may also maintain a list of banned pubkeys: users whose posts or requests should not be approved.🧰 Tools
🪛 LanguageTool
[grammar] ~169-~169: The modal verb ‘should’ requires the verb’s base form.
Context: ...sers who's posts or requests should not approved. ```jsonc { "pubkey": "<32-bytes low...(MD_BASEFORM)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge Base: Disabled due to data retention organization setting
📒 Files selected for processing (1)
72.md(3 hunks)
🧰 Additional context used
🪛 LanguageTool
72.md
[uncategorized] ~116-~116: These words/punctuation marks might seem a little out of order. For clarity and coherence, try switching them around.
Context: ...is does not require approval and should be always honored. ```jsonc { "pubkey": "<32-...
(AI_EN_LECTOR_REPLACEMENT_WORD_ORDER)
[style] ~150-~150: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ntent": "", // other fields... } ``` Moderators may also maintain a list of declined pu...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~168-~168: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ntent": "", // other fields... } ``` Moderators may also maintain a list of banned pubk...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[grammar] ~169-~169: The modal verb ‘should’ requires the verb’s base form.
Context: ...sers who's posts or requests should not approved. ```jsonc { "pubkey": "<32-bytes low...
(MD_BASEFORM)
| A removal 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`). | ||
|
|
There was a problem hiding this comment.
Correct removal event tag description
The parenthetical note still refers to “approval notifications” within a removal context. Update to accurately describe removal notifications:
- A removal 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 removal 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 removal notifications).📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| A removal 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`). | |
| A removal 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 removal notifications). `a` tag prefixes can be used to disambiguate between community and replaceable event pointers (community `a` tags always begin with `34550`). |
🤖 Prompt for AI Agents
In 72.md around lines 82 to 83, the parenthetical note incorrectly refers to
"approval notifications" in the context of removal events. Update the note to
accurately describe removal notifications by replacing "approval notifications"
with the correct term related to removal events, ensuring the description
matches the removal event context.
This is our draft before proposing to the upstream NIPs repo.
Summary by CodeRabbit