laantungir/blossom
1
0
Fork 0
mirror of https://github.com/hzrd149/blossom.git synced 2025-12-08 22:58:51 +00:00
Code Issues Packages Projects Releases Wiki Activity

remove recurring payments

Browse Source
This commit is contained in:
quentintaranpino
2024-12-03 13:03:23 +01:00
parent 3cb8c92197
commit 4d9b22a96c
1 changed files with 1 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
buds/07.md
View File

@@ -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. 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 ### 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. 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 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.