Recurring payments.

This commit is contained in:
Quentin
2024-11-20 12:35:18 +01:00
parent 0aa5a9dd6f
commit 8600dbecfc

View File

@@ -85,6 +85,18 @@ Example for Lightning:
X-Lightning: "966fcb8f153339372f9a187f725384ff4ceae0047c25b9ce607488d7c7e93bba" X-Lightning: "966fcb8f153339372f9a187f725384ff4ceae0047c25b9ce607488d7c7e93bba"
``` ```
### Recurring Payments
Servers MAY accept recurring payments for blob storage using the following Nostr event types:
- **Cashu**: Using [NIP-61](https://github.com/nostr-protocol/nips/blob/master/61.md) for details.
- **Lightning**: Using [NIP-57](https://github.com/nostr-protocol/nips/blob/master/57.md) for details.
The event MUST include a custom `x` tag containing the hash of the blob being paid for.
- `x`: A string that represents the blob's SHA-256 hash.
### Error handling ### Error handling
If the client fails to provide the payment proof (expired invoice, invalid token, etc.) the server MUST respond with **402 Payment Required** status code and include the relevant `X-{payment_method}` header(s) with updated payment details. If the client fails to provide the payment proof (expired invoice, invalid token, etc.) the server MUST respond with **402 Payment Required** status code and include the relevant `X-{payment_method}` header(s) with updated payment details.
@@ -96,3 +108,5 @@ To support future payment methods (e.g., other Layer 2 solutions), the specifica
New methods MUST use a unique `X-{payment_method}` header containing the specific payment details. New methods MUST use a unique `X-{payment_method}` header containing the specific payment details.
New methods MUST adhere their own specification, which MUST be publicly available and linked in the header. New methods MUST adhere their own specification, which MUST be publicly available and linked in the header.
New methods MAY have a Nostr event type for recurring payments, which MUST be linked in the Recurring Payments section.