From 4d9b22a96c3c8ed76bb6001a7898d4c864fcdb0d Mon Sep 17 00:00:00 2001 From: quentintaranpino Date: Tue, 3 Dec 2024 13:03:23 +0100 Subject: [PATCH] remove recurring payments --- buds/07.md | 16 +--------------- 1 file changed, 1 insertion(+), 15 deletions(-) diff --git a/buds/07.md b/buds/07.md index 8b5dde3..8b4bb3e 100644 --- a/buds/07.md +++ b/buds/07.md @@ -89,18 +89,6 @@ X-Lightning: "966fcb8f153339372f9a187f725384ff4ceae0047c25b9ce607488d7c7e93bba" The HEAD endpoints are only used to retrieve blob or server information. They MUST NOT be retried with payment proof. Instead, clients should complete the payment and proceed with the `PUT` or `GET` request. -### 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) standard. - -- **Lightning**: Using [NIP-57](https://github.com/nostr-protocol/nips/blob/master/57.md) standard. - -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 If the client fails to provide the payment proof (expired invoice, invalid token, etc.) the server MUST respond with **400 Bad request** status code and include a `X-Reason` header with a human-readable message. The client SHOULD inform the user about the error and provide a way to retry the request. @@ -111,6 +99,4 @@ 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 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. +New methods MUST adhere their own specification, which MUST be publicly available and linked in the header. \ No newline at end of file