NIP-63

Exclusive Content

draft optional

This NIP specifies how to do paywalled/gated/locked/privileged/protected/paid/subscriber/restricted/premium content on Nostr.

The idea is that a content-creator should be able to manage a list of exclusive-readers who have access to their exclusive content, then choose some specific relays to publish their content based on their known support for this NIP.

Relays that support this NIP (as they could indicate in their NIP-11 responses) should receive the list of users and use it together with NIP-42 authentication in order to decide what content will be readable by each requester.

Exclusive event

Any event can be exclusive, all it needs is a NIP-70 ["-"] tag and another tag ["nip63"] that clearly indicates its status.

(Because normal relays won't care about these tags it's enough for the content-creator to release the event to these relays in order to make it "public" to everybody.)

Membership Event

Membership events must be sent directly to the relays that hold the exclusive content. By default relays should not serve these events to anyone, only to the content-creator directly. Because of this, these lists can be kept reasonably private as long as the content-creator is discreet in his publishing, but can also be made public by being published to other relays.

The lists are constituted of one event for each exclusive-reader, and their removal/update must be done with a NIP-09 deletion request.

{
  "kind": 1163,
  "pubkey": "<content-creator>",
  "tags": [
    ["p", "<exclusive-reader>"]
  ],
  // ...other fields
}

Besides marking individual public keys as readers it's also possible to tag a replaceable list, identified by its address:

{
  "kind": 1163,
  "pubkey": "<content-creator>",
  "tags": [
    ["a", "<kind>:<pubkey>:<d-tag>"],
  ],
  // ...other fields
}

This allows for an easy way to, for example, automatically mark all the people the content-creator follows as allowed to read. Or people who are in a specific kind:30000 follow-set.

More importantly, it allows the content-creator to delegate inclusion of readers to, for example, a payment provider, such that someone can pay and immediately become a exclusive-reader without having to wait until the content-creator is online again to update sign a new event.

It remains a requirement that lists referenced in "a" tags here are sent directly to the relays that hold the exclusive content, such that these relays don't have to go around trying to find such lists.

Relay behavior

A relay that implements this NIP should:

signal 63 in its supported_nips NIP-11 field;
accept kind:1163 events and not serve them to anyone except to their creator;
accept events referenced by "a" tags in kind:1163 events it has accepted;
accept deletion requests for such events;
accept exclusive events containing ["-"] and ["nip63"] tags only from their creator;
only serve the exclusive events to users that have a matching kind:1163 (directly or indirectly);
serve an AUTH challenge to any client opening a connection immediately.

Client behavior

A client doesn't have to do much in order to access exclusive content: if a client is already very liberal with its authentication policies it will automatically perform NIP-42 AUTH whenever it connects to the relay; otherwise it may want to check if such relay supports 63 before deciding.

After that, any REQs should include exclusive content automatically and transparently. This means that while constructiing a normal "following" feed a client will get the exclusive content automatically and place it in front of the user.

A client may decide to display these events differently if they have the ["nip63"] tag.

Announcement

Optionally a content-creator can announce that they have exclusive content available by publishing an event:

{
  "kind": 10163,
  "content": "<something about the exclusive content, the price and other stuff, optionally>",
  "tags": [
    ["url", "<payment-page-url>"]
  ]
}

Where <payment-page-url> is a normal webpage that may have anything in it. From there on, payments are handled off-protocol. The entity that handled the payment is expected to somehow modify the list of exclusive-readers or enable the user to modify it later.

Zap relationship

This NIP is payment agnostic, but that doesn't mean one shouldn't use zaps or nutzaps for this. Clients or third-party services may offer a feature to read all zaps, compute their sums according to any criteria and use that information to modify the list of exclusive-readers.

Future additions

private group announcements: NIP-29 closed groups for subscribers can be announced on the kind:10163.
tiered membership: custom tiers for fine-grained content access control can be added by adding a tag like ["tier", "a"] to the kind:1163 event and using a ["nip63", "a"] tag in the events, for example.
teaser events: perhaps a ["nip63", "", "-"] (negative) tag could cause an event to be displayed only to those that do not have access to its exclusive counterpart, this would also be managed by the relay.
relays for exclusive content different from the outbox relays?
individual "pay-per-view" content.

5.3 KiB Raw Blame History