NIP-60

Zap Gates

draft optional author:egge author:starbuilder

The purpose of this NIP is to allow external resources that are protected by NIP98 HTTP-AUTH to be unlocked through zaps. It enables creators to limit access to resources and only let public keys that have paid for it access.

Creating Zap Gated Resources (Creator)

In order to create a Zap Gated Resource a creator uploads the resource (e.g, a text-, audio-, or image-file) to a NIP-60 enabled provider, specifying a price, the public key that will be used to publish the event, a payment destination according to NIP-57, as well as a list of relays that should be used for zapping. The provider returns an unsigned event of kind 1211, containing relevant metadata and the resource url that the creator can then sign and publish.

Protecting a Zap Gated Ressource (Provider)

Zap Gated Resources are protected using NIP-98 HTTP Auth. In order to only return the resource to users that have paid for the resource, the provider keeps track of all the Zap events on the specified relays that are targeting the event-id of a kind 1211 event and curates a list of public keys that have zapped at least the amount specified by the creator when initially uploading the resource. If the NIP-98 AUTH header in the request matches one of those keys, the provider should respond with status code 200 and the requested resource, otherwise it should respond with a status code 402.

Accessing a Zap Gated Resource (User)

When a client discovers a kind 1211 event, it should render the preview if applicable and let the user know that they need to pay in order to view the full resource (e.g., by showing a "pay to unlock" button). If the user wishes to pay for the resource, the client should facilitate a Zap according to NIP-57 on the kind 1211 event, specifying the relays from the kind 1211 event relays tag. After successful payment it should go ahead and construct an AUTH header according to NIP-98 and request the full resource from the url in the kind 1211 event.

Exemplary Flow

Alice uploads a podcast episode she recorded to a NIX-60 enabled provider, constructs a kinds 1211 event with the providers help and then publishes said event to the relays of her choice. The provider begins watching for Zap Receipts with an e tag matching Alice's kinds 1211 event.
Bob discovers Alice's kind 1211 event in his feed. In order to request the resource Bob's client will construct a Authorization HTTP header per NIP98 and add it to the request. Because Bob has not yet paid for it the provider will respond with a 402 Payment required. Bob's client will render the appropriate UI with the content preview, the resource's price and a button to initiate payment.
If Bob wishes to purchase the resource he will ask his Client to zap Alice's kind 1211 event with at least the amount specified in the amount tag. Because the provider needs to be aware of this Zap, they included a relays tag in the kind 1211 event when it was constructed in Step 1. These relays must be included in Bobs NIP57 Zap-Request event so that the Zap Provider knows to publishes the NIP57 Zap Receipt to the same set of relays.
Once the provider receives information about Bob's Zap Receipt it will verify its integrity and if it's amount is >= the amount specified in the kinds 1211 event it will add Bob's public key to a list of authorized public keys.
After the zap per NIP57 is completed Bob's client can request the resource again, still adding authentication per NIP98. Because the provider has added his public key to the authorized public keys it will no longer respond with 402 Payment required, but with 200 and the requested resource.

Kind 1211 Event format

This NIP specifies a 1211 event kind for Zap Gated Resources, having in content a description of the protected resource, and a list of tags described below:

u the url of the NIP-98 protected resource
m a string indicating the data type of the file. The MIME types format must be used (https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types)
amount the price in SATS that is to be paid to access the resource.
relays a list of relays that should be used for zapping.
preview (optional) a preview of the protected ressource that should be accessible prior to paying (see preview examples)

{
  "id": <32-bytes lowercase hex-encoded sha256 of the the serialized event data>,
  "pubkey": <32-bytes lowercase hex-encoded public key of the user>,
  "created_at": <unix timestamp in seconds>,
  "kind": X,
  "tags": [
    ["u",<string with URI of file>],
    ["m", <MIME type>],
    ["amount", <price in SATS>],
    ["preview",<preview tag> ],
    ["relays", <list of relays>]
  ],
  "content": <description>,
  "sig": <64-bytes hex of the signature of the sha256 hash of the serialized event data, which is the same as the "id" field>
}

Preview Tag

for images: ['blurhash': <blurhash>] or ['imagefile': <preview image url>]
for audio: ['audiofile': <preview audio url>]
for text: ['excerpt': <text>] or ['textfile': <preview text url>]

Considerations and Extensions

Privacy

To avoid leaking information about purchases (when zapping a kind 1211 event) a user can derive a throw-away keys. Because the key is only used to create the Zap Request and then attached to the resource request, clients can create key-pairs on a per purchase basis and either keep track of them locally or implement a standardized derivation method.

Payment Splits

Instead of only specifying a single zap target, kind 1211 events could hold more than one target, providing instructions for clients to "split" the zap. There are several use cases for this, like co-authoring of content, but also revenue splits for providers.

5.8 KiB Raw Blame History