remove recurring payments

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.