BUD-07 Paid storage

[quentintaranpino]

This pull request introduces BUD-07, which outlines how servers can require and handle payments for blob storage. This specification allows servers to inform clients if a payment is needed for uploading or accessing a blob, either by rejecting the request upfront or by requiring payment after the upload is completed.

Readable version here

Key Features of BUD-07:

This specification introduces payment requirements for blob storage, allowing servers to manage payments both before and after an upload. When payment is required, the server uses the Www-Authenticate header and the L402 protocol standard to return a 402 Payment Required status code, along with payment details such as macaroon and invoice.

This mechanism ensures that clients are informed if payment is necessary before an upload or access attempt, or even after an upload is completed.

These endpoints MUST return a 402 Payment Required status code and a Www-Authenticate header when the payment is required.

• HEAD /upload
• PUT /upload
• HEAT /
• GET /

Authenticate header

The Www-Authenticate header is a standard HTTP header field that defines the authentication method that should be used to gain access to a resource. It is used by the server to challenge the client to authenticate itself. Using the L402 protocol, the Www-Authenticate header can be used to request payment for specific blobs.

The Www-Authenticate header contains the macaroon and invoice fields for servers and the macaroon and preimage fields for clients.

• macaroon A base64 encoded string containing the macaroon, see L402 macaroons.
• invoice A string containing LN the payment request.
• preimage A string containing the payment preimage.

Client-Side Handling: For clients that do understand the 'Www-Authenticate' header, they can display the invoice and facilitate payment directly, ensuring a seamless upload process once payment is completed using L402 standard.

Server-Side Handling: Thanks to the L402 protocol, the server can directly validate the client's payment within the request by using the preimage of the Lightning invoice, ensuring that the payment has been made before processing the blob storage or access without relying on a Lightning node or third-party services.

Backward Compatibility: For clients that do not support or interpret the Www-Authenticate header, the server will still return the appropriate 402 Payment Required status code. However, to maintain compatibility and user experience, the server will allow uploads to proceed but will display a payment request (QR code, text string, JSON, etc.) when the client tries to access the uploaded content. This ensures smooth interaction with not compatible clients, while enabling the server to enforce payment for storage or access.

Example
Here is an example of a QR code generated by nostrcheck-server for the url field as long as a payment has not been made:

[hzrd149]

Looks great, a few formatting fixes and one comment. but I really like how simple this is