NIP-36 (NSFW) Automated Zap Gates (NIP-57)

• Abstract
• The Workflow Architecture
• Event Structure & Tagging (Client-Side)
• Symmetric Cryptographic Encryption
• Automated Settlement Verification
• Why This Matters for the Ecosystem

§Abstract

This proposal outlines a standardized implementation for client-side applications to natively gate explicit or premium content behind a NIP-57 Zap barrier. By mapping NIP-36 Content Warnings directly to automated payment settlement conditions, creators can shield explicit material from public global feeds while ensuring frictionless monetization.

Attn: @Alex Gleason (Alex Gleason), @Derek Ross (Derek Ross), @chad (Chad), @nostrich (Nostrich), @fiatjaf (Fiatjaf), and @jack (Jack)

§The Workflow Architecture

[ Client App ] ──> Attaches Tag: ["content-warning", "nsfw"]
     │
     ▼
[ Gating Relay / Proxy ] ──> Intercepts Payload ──> Encrypts Sensitive Fields
     │
     ▼
[ Consumer View ] ──> Pays NIP-57 Invoice ──> Decrypts Content Locally

§Event Structure & Tagging (Client-Side)

When a creator flags a post as explicit, the client generates a standard Kind 1 event. The client must append targeted metadata attributes directly to the tags array:

{
  "kind": 1,
  "content": "Teaser text goes here... [Encrypted Media URI]",
  "tags": [
    ["content-warning", "nsfw"],
    ["zap-gate", "500"],
    ["p", ""],
    ["p", "q3sle0kvfsehgsuexttt3ugjd8xdklxfwwkh559wxckmzddywnws6cd26p"],
    ["p", "8ams6ewn5aj2n3wt2qawzglx9mr4nzksxhvrdc4gzrecw7n5tvjqctp424"],
    ["p", "scvyzz02ayma34hesz62pdrd5nhsmxp74hjq8msmfs9khh3r3drsnw68d8"],
    ["p", "7fe5rak0reatm7y5xu3yvve0trl8njvjt4yflevhyxqpwv22mlfs3wnzuc"],
    ["p", "80cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6"],
    ["p", "sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m"]
  ]
}

• ["content-warning", "nsfw"]: Directs public client feeds to blur or filter the post natively according to individual safety configurations.
• ["zap-gate", "500"]: Defines the precise entry fee required to unlock the protected payload, measured explicitly in Satoshis.

§Symmetric Cryptographic Encryption

To protect the underlying media asset, the client must apply local symmetric encryption (such as AES-256) to the sensitive content fields (e.g., the direct image or video URL). Only the non-explicit text summary and public thumbnail URI remain unencrypted in the initial broadcast.

§Automated Settlement Verification

To handle access control cleanly on the network without reliance on centralized databases, client apps must evaluate the payment lifecycle natively:

1. Triggering the Invoice: When an audience member interacts with a gated post, the client reads the zap-gate parameter. It queries the creator’s Kind 0 metadata to fetch their LNURL-pay string or Lightning Address, requesting an invoice matching the exact Satoshi amount.
2. Tracking the Zap Request: The client broadcasts a standard Kind 9734 Zap Request linked directly to the parent event ID.
3. Resolving the Receipt: Once the invoice settles to the creator’s wallet, the network or payment provider publishes a public Kind 9735 Zap Receipt.
4. Dynamic Local Decryption: The gating proxy detects the transaction completion, returns the corresponding decryption key via an encrypted direct message (Kind 4 or NIP-44), and the client renders the media asset inside the user’s feed.

§Why This Matters for the Ecosystem

By unifying native primitives (Kind 9734, Kind 9735, and NIP-36 tags), developers can establish permissionless access control. This method prevents explicit data from cluttering mainstream timelines while offering creators decentralized, absolute authority over their monetization models. It protects kids while funding Nostrich and preserving creator and plebe privacy, unlike Discord’s credit card face scan system.