NIP-63

Relay-based Paywalls

draft optional

This NIP specifies how relays can support paywalled content. Well, "paywall" is a misnomer as this NIP doesn't imply payment necessarily, it's agnostic about that, so better call it premium content.

The idea is that a content-creator should be able to manage a list of premium-reader who have access to their premium 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.

Premium event

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

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 will implement the paywall. 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 discrete in their publishing, but can also be made public by being published to other relays.

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

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

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 deletion requests for such events;
accept premium events containing ["-"] and ["nip63"] tags only from their creator;
only serve the premium events to users that have a matching kind:1163;
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 premium 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 premium content automatically and transparently. This means that while constructiing a normal "following" feed a client will get the premium 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.

Future additions

more private list membership: perhaps doing an HMAC with the public key of the reader and a key that is shared with the relays will be enough for this.
tiered membership: custom tiers for fine-grained content access control can be added by adding more tags to the kind:1163 event and more items to the ["nip63"] tag.
teaser events: perhaps a ["nip63", "teaser"] special tag could cause an event to be displayed only to those that do not have access to its premium counterpart, this would also be managed by the relay.

3.4 KiB Raw Blame History