Work in progress for reasons that will become obvious in the first paragraphs.
——-
Draft NIP — Media Rights & Revenue Terms (v3)
companion spec to the manifesto “Nostr Has the Wrong Half of Bitcoin.” Posted for discussion; tear it apart.*
**Contributions, disclosed.** This spec was drafted in collaboration with an AI assistant (Claude, Anthropic), used as protocol engineer and hostile reviewer.
- *Human author:* the conceptual architecture — infrastructure operators as revenue shareholders; the pull-based “pot” settlement model; monetization as a creator-declared menu of modes with V4V as the default; the requirement that every honest participant — including consuming clients and crowdsourced promoters — can earn from the works they help sell; content as the economic engine that funds the network’s participants; keeping enforcement out of the NIP and at the media-server layer.
- *AI contributions:* mapping these concepts onto Nostr primitives (event kinds, the N-event acceptance handshake, the three participation mechanisms, NIP-60/61 settlement, claim-secret receipts); the self-critique behind section 7; drafting in NIP house style.
The ideas, the positions taken, and any remaining mistakes are mine; I am the accountable party and will answer objections personally.
-----
## What this is
A standard way for creators to declare, in a single signed event, how a published work may be supported financially, and how incoming value divides among **every participant in its success** — collaborators, hosts, publishing tools, consuming clients, and promoters alike.
It introduces no gating, no DRM, and no changes to any existing media NIP. **Value-for-Value (zaps) is the first and default mode.** A solo creator declaring “zaps welcome, 100% to me” uses this spec in one tag and is done.
## Design principle (the iron law)
**Rewards attach to settlements, never to attention.** The only unforgeable event in a media economy is the payment itself; claims of impressions, views, or engagement are forgeable and are therefore worth nothing here. Every reward in this spec is a share of a real payment, claimable only by a party whose contribution to *that payment* is verifiable. This is deliberate: paying for attention rebuilds engagement farming; paying on conversion builds an economy.
## Motivation
Revenue terms on Nostr today are scattered and implicit: zap splits live in ad-hoc tags, collaborator arrangements happen off-protocol, hosting costs are externalized, and the developers who deliver audiences earn nothing protocol-native. A supporter zapping a song cannot verify that the producer, the vocalist, and the server hosting the file each receive their agreed share. A media server has no way to say “I will host this work for 10% of its revenue.” A client developer has no answer to “why build for this network?”
This proposal gives every work a public, auditable revenue structure bound to its content hash — and gives every honest participant a way to earn from it.
## 1. The three participation mechanisms
Participants differ by **when they become known**, so the spec defines exactly three mechanisms — fixed forever; new participant types are labels on top, never new protocol:
**A. Table shares** — for parties known at publish time (creators, publishing client, media hosts, contracted promoters). Declared in the Terms event, committed via the acceptance handshake, durable.
**B. Pools** — for parties known only at payment time (the crowdsourced promoter who converted this buyer; the client that constructed this settlement). The creator reserves a percentage of gross; the occupant is determined per-settlement by a verifiable claim. Unclaimed pool funds flow back to the table.
**C. Additive fees** — disclosed surcharges on top of the price, set by the consuming client, paid knowingly by the payer. Never carved out of anyone’s share; competition can drive them to zero.
## 2. Terms Event
A *Terms event* is an addressable event of provisional `kind:37501`, published by the work’s principal author.
```json
{
"kind": 37501,
"pubkey": "<creator-pubkey>",
"tags": [
["d", "<work-identifier>"],
["title", "Night Drive — Official Video"],
["x", "<sha256-of-media-blob>"],
["a", "21:<creator-pubkey>:<d-tag-of-video-event>"],
["mode", "zap"],
["mode", "ppv", "2100", "sat"],
["mode", "purchase", "210000", "sat"],
["mode", "subscription", "10000", "sat", "month"],
["share", "<director-pubkey>", "40", "creator"],
["share", "<composer-pubkey>", "30", "creator"],
["share", "<editor-pubkey>", "15", "creator"],
["share", "<blossom-operator-pubkey>", "10", "infrastructure"],
["share", "<publishing-client-pubkey>", "5", "service"],
["pool", "promotion", "10"],
["pool", "delivery", "5"],
["p", "<each-shareholder-pubkey-one-tag-each>"],
["mint", "
https://mint.example", "sat"],
["parent", "37501:<other-pubkey>:<parent-work-id>", "10"]
],
"content": "<optional human-readable license / terms text>"
}
```
### Tags
- `d` — stable work identifier. RECOMMENDED: the sha256 of the primary blob, making the terms address derivable from the file itself.
- `x` (one or more) — sha256 hashes of the covered blobs. Binds terms to content, not URLs (compatible with Blossom, NIP-B7).
- `a` / `e` (optional) — Nostr media events presenting the work (NIP-71, NIP-23, kind:1063). Terms MAY cover a bare blob with no media event.
- `mode` (one or more) — accepted support modes: `zap` (V4V, default), `ppv`, `purchase`, `subscription` as in the example. Clients MUST ignore unknown modes. `["mode","zap"]` alone is a pure V4V declaration and the expected common case.
- `share` (unbounded count) — the split table: `["share","<pubkey>","<weight>","<role>"]`. Weights are relative integers; shares = weight / sum(weights). Roles defined: `creator`, `infrastructure`, `service`; unknown roles MUST be preserved and displayed. Support at least 32 entries.
- `pool` — `["pool","<type>","<percent-of-gross>"]`. Types defined: `promotion` (claimed by the verified converter of this settlement, section 5.1) and `delivery` (claimed by the client constructing this settlement, section 5.2). Unknown pool types MUST be treated as unclaimed. The sum of all pool percentages MUST be below 100.
- `p` (REQUIRED, one per shareholder) — duplicates each share pubkey for relay indexability. A `share` without a matching `p` is invalid.
- `mint` — Cashu mints suggested for settlement. Precedence: a recipient’s own `kind:10019` always wins; terms-level mints are fallback hints.
- `parent` (optional) — declares derivation; assigns the parent’s table a collective weight in this work’s revenue. Resolve one level; deeper recursion optional.
### 2.1 Authority — who may publish Terms for a work
A hash proves nothing about authorship. A Terms event is **valid** only if at least one of:
1. Its author authored a referenced media event (`a`/`e` match), or
1. A media event signed by the work’s author forward-references it (`["terms","<address>"]`), or
1. For bare blobs: the Terms author is the authenticated uploader, attested in the hosting server’s acceptance.
Competing claims on one hash MUST NOT be auto-resolved by timestamp; resolution is web-of-trust, and contested claims MUST be surfaced visibly. This makes false claims detectable and attributable — signed — not impossible. No system can prove authorship from a hash.
### 2.2 Versioning
Terms are addressable, therefore mutable; each revision has a new event `id`. Commitments pin specific ids. The *active* version is the latest revision satisfying section 3.
## 3. Deal Acceptance — the N-party handshake
Each shareholder whose share is a commitment (typically `infrastructure`/`service` — parties providing something for their points) publishes an Acceptance, provisional `kind:7501`:
```json
{
"kind": 7501,
"pubkey": "<blossom-operator-pubkey>",
"tags": [
["e", "<terms-event-id>"],
["a", "37501:<creator-pubkey>:<work-identifier>"],
["p", "<creator-pubkey>"],
["commitment", "hosting", "
https://media.example"],
["term", "<unix-expiry-timestamp>"]
],
"content": "Accepted: hosting and CDN for 10% share until expiry."
}
```
The `e` tag binds acceptance to one exact revision. Publishing an Acceptance REQUIRES a published `kind:10019` mint list — you must be payable to be a shareholder.
### 3.1 Deal windows
Every Acceptance carries a `term` (expiry); deals are renewable windows. **Within a window**, a revision removing or reducing a committed shareholder does not activate without that shareholder’s Acceptance of the new revision — the prior revision stays active until expiry. **At expiry**, both sides walk free. This resolves the rug-vs-hostage dilemma without multisig. Creator-role shareholders need not accept (the author signs the Terms; co-creators receive without action). A solo V4V work requires no acceptances and is active on publication.
## 4. Settlement
Pull-based, on NIP-60/61. The payer’s client computes the division (section 5), then issues per recipient a NIP-61 nutzap (`kind:9321`) P2PK-locked to them, `e`-tagging the Terms event id honored. Rounding remainders go to the highest-weight table share. The result is the **pot**: locked ecash on relays, spendable only by each recipient, redeemable on their own schedule. No custodial coordinator; no atomic multi-destination route; offline recipients lose nothing.
## 5. Division algorithm
For a settlement of gross G:
1. For each declared pool with a **valid claim** (below): allocate `percent × G` to the claimant.
1. Pools without a valid claim allocate nothing; their funds remain in the remainder.
1. The remainder divides across the table per weights.
1. Additive fees (section 5.3) are charged on top of G and never alter steps 1–3.
### 5.1 Promotion pool — the converter’s claim
When a payer arrives at a work via someone’s repost, quote, or recommendation event, the payer’s client MAY attach to the settlement a conversion reference: `["via","<event-id>","<promoter-pubkey>"]`. The claim is **valid** iff the referenced event (a) exists, (b) is signed by the claimed promoter, (c) references the work (its media event, Terms event, or blob hash), and (d) predates the settlement. The promotion pool’s cut locks to the promoter.
This turns every viewer into potential sales force: watch, love it, repost, earn when your followers buy. Reach is paid **only on conversion** — never on impressions (see the iron law).
Honest bound: an open system cannot stop a buyer claiming their own repost. The worst case is therefore a **self-discount bounded by the pool percentage** — a creator declaring a 10% promotion pool is honestly declaring “up to 10% off for the savvy, commission otherwise.” Creators who can’t live with that set it to zero.
### 5.2 Delivery pool — the client’s claim
The client application that constructs the settlement claims the delivery pool by locking its cut to its own declared pubkey and tagging the settlement `["client","<pubkey>"]`. The claim is valid by construction — the claimant verifiably *is* the party that processed this transaction; it is the strongest claim in the system. This is the standing answer to “why build a media client for Nostr”: a creator-declared, protocol-wide revenue share to whoever brings the buyer. Clients that waive their claim simply leave the funds to the table.
### 5.3 Additive client fees
A consuming client MAY additionally charge a disclosed fee on top of the price (“2,100 sats + 50 sats client fee”), locked to its own pubkey. Fees MUST be displayed before payment and MUST NOT reduce any table or pool amount. Gating servers (Appendix A) verify table and pool outputs exactly and permit additional self-disclosed outputs — skimming structurally fails; surcharging transparently succeeds. Fee-free clients compete on zero.
## 6. Receipts
For priced modes, the **serving party** publishes the receipt, provisional `kind:7503` (no payer pubkey):
```json
{
"kind": 7503,
"pubkey": "<server-pubkey>",
"tags": [
["e", "<terms-event-id>"],
["a", "37501:<creator-pubkey>:<work-identifier>"],
["mode", "ppv"],
["amount", "2100", "sat"],
["via", "<conversion-event-id>", "<promoter-pubkey>"],
["client", "<client-pubkey>"],
["claim", "<hash-of-payer-supplied-claim-secret>"]
],
"content": ""
}
```
- **Payer privacy:** no payer identity on-relay; the `claim` hash lets the payer later prove “I paid for this” by revealing the preimage.
- **Portable access:** the receipt is a cross-server credential — any server hosting the same hash under the same Terms MAY honor proof of the claim secret for `purchase`/`subscription`. Payment at one mirror opens cooperating mirrors; Blossom’s resilience is preserved, not fractured.
- **Public support, optionally:** payers wanting visible attribution MAY also zap publicly or publish their own receipt. Privacy is default; flexing is a choice.
- Pool attributions (`via`, `client`) in receipts make promoter and client earnings publicly auditable.
## 7. Trust Model & Known Limitations
Stated plainly so reviewers don’t have to discover these:
1. **Splits are enforced by client defaults, auditability, and gating servers — not mathematics.** Same trust level as NIP-57 splits today, plus verifiability, plus hard enforcement wherever a gating server is in the path.
1. **Within a deal window, defection is detectable, not preventable.** Both sides leave signed evidence; reputation is the court.
1. **Receipts audit settlements; they do not measure popularity.** Insiders can wash-trade their own works at the cost of fees only. Receipt counts MUST NOT naively drive rankings or pool divisions. Outsider forgery costs full price, paid to the shareholders.
1. **The promotion pool is also a bounded self-discount** (section 5.1). Priced, capped, creator-controlled — a feature with a known cost, not an exploit.
1. **Referral incentives will produce some promotional spam.** The incentive is conversion, not impressions: muted promoters reach no one and earn nothing, so mutes and web-of-trust double as market regulation. Untested at scale; flagged honestly.
1. **The pot is mint-custodial.** Unredeemed ecash is a claim on a Cashu mint. Redeem regularly; diversify mints. Inherited from NIP-60/61.
1. **Gating buys practical scarcity, not cryptographic scarcity.** A paying customer can mirror a blob. The goal is making paying easier than pirating; encrypted-blob key-sale (Future Work) is the stronger construction.
1. **Authorship cannot be proven from a hash** (section 2.1). Claims are attributable and contestable; ground truth stays social.
## 8. Relationship to existing work
NIP-57/60/61 (settlement rails — this adds division logic and auditable terms); NIP-71, NIP-23, NIP-94/1063, Blossom NIP-B7 and BUDs (media presentation and addressing, untouched); NIP-89 (rights-aware clients SHOULD announce handler support for `kind:37501`); NIP-90 (creator/host matchmaking is a natural DVM job, out of scope); zap prisms and prior zap-split experiments (prior art in cascading splits, acknowledged).
## 9. Future Work
Advertising-funded modes (excluded: impression counting without payment linkage is Sybil-vulnerable); encrypted-blob distribution with key sale; deep derivative cascades; threshold-signed Terms (FROST/MuSig2 compressing the handshake); usage-weighted subscription pools (blocked on limitation 3); a relay pool type, if a verifiable “served the terms” claim is ever designed — today it is the weakest claim in the system and is deliberately omitted.
-----
## Appendix A — Companion BUD outline: Split-Verified Paid Serving
*(To be proposed in the Blossom repository if this gains traction.)*
Opt-in server capability for priced modes:
1. `GET /<sha256>` on a gated blob → `402 Payment Required` with the Terms address and accepted mints.
1. The client constructs the settlement per section 5: pool outputs to valid claimants (including its own delivery claim), table outputs per weights, optional additive fee to itself, plus a fresh claim-secret hash.
1. Retry with `Authorization: Nutzap <base64>`.
1. The server verifies offline (DLEQ proofs + published Terms): table and pool amounts and lock keys match exactly; `via` claims are checked against the referenced conversion event (invalid ⇒ pool treated as unclaimed, funds must appear in the table outputs); **additional self-disclosed outputs are permitted** (additive fees). On success: serve, publish the nutzaps and the `kind:7503` receipt.
1. `purchase`/`subscription`: any participating server hosting the same hash grants access on proof of the claim secret — payment at one mirror opens all cooperating mirrors.
The payment **is** the access credential: a settlement that shorts any shareholder or pool claimant fails verification and opens no door. The operator enforces everyone’s split because its own share rides in the same token.
-----
*Provisional kinds (37501, 7501, 7503) are placeholders pending review. V4V remains the default and simplest mode throughout; nothing here gates, replaces, or discourages zaps.*
