Skip to content

Kind 4550: Community Post Approval ​

Overview ​

Community Post Approval events (kind 4550) are used by moderators to approve posts for inclusion in moderated communities. These events represent the moderation layer of the NIP-72 community system, allowing designated moderators to curate what content appears within a community. Any post in a Nostr community requires approval through a kind 4550 event before it can be considered part of that community.

Specification ​

PropertyValue
Kind Number4550
Event RangeRegular
Defined inNIP-72

Content Format ​

The content field must contain the full JSON-encoded event being approved. This ensures that even if the original post is modified or deleted, the approved version remains available.

Schema ​

json
"content": "<JSON-encoded original post event>"

Tags ​

Tag NameDescriptionFormatRequired
aCommunity reference["a", "34550:<pubkey>:<d-identifier>", "<relay-url>"]Yes
ePost event reference["e", "<event-id>", "<relay-url>"]Yes*
aReplaceable post reference["a", "<type>:<pubkey>:<d-identifier>", "<relay-url>"]Yes*
pPost author reference["p", "<pubkey>", "<relay-url>"]Yes
kPost event kind["k", "<kind-number>"]Yes

*Either an e tag or an a tag (or both) must be used to reference the post being approved, depending on the approval strategy.

Client Behavior ​

Clients should:

  1. Only display posts in a community that have valid approval events from the community's moderators
  2. When showing a moderated community:
    • Fetch community definition (kind 34550) to identify moderators
    • Fetch post approval events (kind 4550) from those moderators
    • Display only approved posts in the community view
    • Use the post kind from the k tag to allow filtering by event type
  3. For clients used by moderators:
    • Provide an interface for reviewing and approving community posts
    • Generate proper kind 4550 events with all required tags
    • Include the full JSON-encoded original post in the content
  4. Handle deletion requests (kind 5) targeting approval events as revocation of approval
  5. For replaceable events, implement the three approval strategies:
    • When using e tag only: Approval applies to only that specific version
    • When using a tag only: Approval applies to all versions by that author
    • When using both: Display version history with appropriate UI

Relay Behavior ​

Relays should:

  1. Store post approval events alongside the posts themselves
  2. Honor deletion requests for approval events
  3. Make approval events discoverable through standard filters

Use Cases ​

  • Moderating content in topic-based communities
  • Approving posts for inclusion in curated spaces
  • Creating spam-free discussion environments
  • Implementing community standards and guidelines
  • Enabling content curation by trusted moderators
  • Building Reddit-style community structures
  • Supporting multi-moderator approval workflows

Example ​

json
{
  "id": "c8c87a8fd7c5c427fb2a6cf365d95e0f1c6ebefcf993118ce539e57f8e971c75",
  "pubkey": "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d",
  "created_at": 1684324000,
  "kind": 4550,
  "tags": [
    ["a", "34550:32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245:nostr-dev", "wss://relay.nostr.band"],
    ["e", "df0be4d4505c044c1063059e76db26cac90cf59a0be1e4e01fbef72012eac9e6", "wss://relay.nostr.band"],
    ["p", "854043ae8f1f97430ca8c1f1a090bdde6488bd5115c7a45307a2a212750ae4cb", "wss://relay.nostr.band"],
    ["k", "1"]
  ],
  "content": "{\"id\":\"df0be4d4505c044c1063059e76db26cac90cf59a0be1e4e01fbef72012eac9e6\",\"pubkey\":\"854043ae8f1f97430ca8c1f1a090bdde6488bd5115c7a45307a2a212750ae4cb\",\"created_at\":1684323950,\"kind\":1,\"tags\":[[\"a\",\"34550:32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245:nostr-dev\",\"wss://relay.nostr.band\"]],\"content\":\"Has anyone implemented NIP-72 communities in their client yet?\",\"sig\":\"a9a4e2192eede77e6c9d24ddfab95ba3ff7c03fbd07ad011fff245abea431fb4d3787c2d04aad001cb039cb8de91d83ce30e9a94f82ac3c5a2372aa1294a96bd\"}",
  "sig": "915b6f8c1033a1a4f0c4b0f9bb46f3b1c071725f7c204bc1b3aa948b3098d0edd3487a9b387592ce3c9f095c4d30ccc0ed5d8be46f39933c46065a1742e3ec91"
}

Approval Strategies for Replaceable Events ​

NIP-72 defines three strategies for approving replaceable events:

  1. Version-Specific Approval (e tag only):

    • Approves only the specific version of the event
    • Requires new approvals for any updates to the event
    • Useful for strict moderation where all changes need review
  2. Author-Wide Approval (a tag only):

    • Approves all versions of the replaceable event by that author
    • Author can update without requiring new approvals
    • Good for trusted authors who may need to update content
  3. Full History Approval (both e and a tags):

    • Provides approval for current and future versions
    • Preserves the specific version being approved
    • Enables clients to show history with appropriate UI indicators

References ​

Notes ​

  • It's recommended that multiple moderators approve posts to develop resilience
  • If a moderator is removed, their approval events may still be valid depending on client implementation
  • When moderator rotation happens, new moderators may need to re-approve existing posts
  • Clients may implement different policies on how many moderator approvals are needed
  • The community owner can periodically re-sign approvals to ensure continuity
  • For cross-posting, events can be approved in multiple communities with separate approval events
  • In case of replaceable event approval, the content must contain the specific approved version if using e tag
  • Clients should evaluate non-34550:* a tags as posts to be approved for all 34550:* a tags