mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-26 18:25:51 -05:00
formatting + readme
This commit is contained in:
Egge
parent
8571d7807e
commit
f7481be16d
77
60.md
Normal file
77
60.md
Normal file
|
|
@ -0,0 +1,77 @@
|
|||
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
|
||||
|
||||
1. 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.
|
||||
|
||||
2. 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.
|
||||
|
||||
3. 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.
|
||||
|
||||
4. 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.
|
||||
|
||||
5. 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)
|
||||
|
||||
```json
|
||||
{
|
||||
"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.
|
||||
|
|
@ -58,6 +58,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/fia
|
|||
- [NIP-56: Reporting](56.md)
|
||||
- [NIP-57: Lightning Zaps](57.md)
|
||||
- [NIP-58: Badges](58.md)
|
||||
- [NIP-60: ZapGates](60.md)
|
||||
- [NIP-65: Relay List Metadata](65.md)
|
||||
- [NIP-78: Application-specific data](78.md)
|
||||
- [NIP-94: File Metadata](94.md)
|
||||
|
|
@ -80,6 +81,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/fia
|
|||
| `42` | Channel Message | [28](28.md) |
|
||||
| `43` | Channel Hide Message | [28](28.md) |
|
||||
| `44` | Channel Mute User | [28](28.md) |
|
||||
| `60` | ZapGate | [60](60.md) |
|
||||
| `1063` | File Metadata | [94](94.md) |
|
||||
| `1984` | Reporting | [56](56.md) |
|
||||
| `9734` | Zap Request | [57](57.md) |
|
||||
|
|
|
|||
77
XX.md
77
XX.md
|
|
@ -1,77 +0,0 @@
|
|||
NIP-XX
|
||||
======
|
||||
|
||||
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 users to limit access to pubkeys that have paid for it.
|
||||
|
||||
## 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-XX 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-X, 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-X 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-X 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-X event, specifying the relays from the kind-X 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-X event.
|
||||
|
||||
## Exemplary Flow
|
||||
|
||||
1. Alice uploads a podcast episode she recorded to a NIX-XX enabled provider, constructs a Kind-X 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 Kind-X event.
|
||||
|
||||
2. Bob discovers Alice's Kind-XX 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.
|
||||
|
||||
3. If Bob wishes to purchase the resource he will ask his Client to zap Alice's kind-X 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-X 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.
|
||||
|
||||
4. 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 Kind-X event it will add Bob's public key to a list of authorized public keys.
|
||||
|
||||
5. 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. Because it might take a few seconds for the Zap Receipt to propagate.
|
||||
|
||||
## Kind-X Event format
|
||||
|
||||
This NIP specifies a `X` event kind for Zap Gated Resources, having in `content` a description of the resource, and a list of tags described below:
|
||||
|
||||
* `url` 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)
|
||||
* `price` 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)
|
||||
|
||||
```json
|
||||
{
|
||||
"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": [
|
||||
["url",<string with URI of file>],
|
||||
["m", <MIME type>],
|
||||
["price", <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 IP addresses (when fetching protected resources) and purchases (when zapping a kind-X 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-X 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.
|
||||
Loading…
Reference in New Issue
Block a user