diff --git a/README.md b/README.md index d7b518e..49c8586 100644 --- a/README.md +++ b/README.md @@ -12,7 +12,7 @@ Blobs are packs of binary data addressed by their sha256 hash ## How does it work? -Blossom Servers expose four endpoints for managing blobs +Blossom Servers expose a few endpoints for managing blobs - `GET /` (optional file `.ext`) [BUD-01](./buds/01.md#get-sha256---get-blob) - `HEAD /` (optional file `.ext`) [BUD-01](./buds/01.md#head-sha256---has-blob) @@ -27,6 +27,9 @@ Blossom Servers expose four endpoints for managing blobs - `Authentication`: Signed [nostr event](./buds/02.md#delete-authorization-required) - `PUT /mirror` [BUD-04](./buds/04.md#put-mirror---mirror-blob) - `Authentication`: Signed [nostr event](./buds/02.md#upload-authorization-required) +- `HEAD /media` [BUD-05](./buds/05.md#head-media) +- `PUT /media` [BUD-05](./buds/05.md#put-media) + - `Authentication`: Signed [nostr event](./buds/05.md#upload-authorization) ## Protocol specification (BUDs) @@ -40,8 +43,9 @@ See the [BUDs](./buds) folder and specifically [BUD-01](./buds/01.md) and [BUD-0 - [BUD-02: Blob upload and management](./buds/02.md) - [BUD-03: User Server List](./buds/03.md) - [BUD-04: Mirroring blobs](./buds/04.md) -- [BUD-07: Paid storage](./buds/07.md) +- [BUD-05: Media optimization](./buds/05.md) - [BUD-06: Upload requirements](./buds/06.md) +- [BUD-07: Paid storage](./buds/07.md) - [BUD-08: Nostr File Metadata Tags](./buds/08.md) ## Event kinds diff --git a/buds/01.md b/buds/01.md index e94b8d4..a087c94 100644 --- a/buds/01.md +++ b/buds/01.md @@ -134,3 +134,9 @@ Example event for retrieving multiple blobs from single server: The `HEAD /` endpoint MUST respond with either a `200` or `404` status code The endpoint MUST accept an optional file extension in the URL similar to the `GET /` endpoint. ie. `.pdf`, `.png`, etc + +## Range requests + +To better support mobile devices, video files, or low bandwidth connections. servers should support range requests ([RFC 7233 section 3](https://www.rfc-editor.org/rfc/rfc7233#section-3)) on the `GET /` endpoint and signal support using the `accept-ranges: bytes` and `content-length` headers on the `HEAD /` endpoint + +See [MDN docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests) for more details diff --git a/buds/02.md b/buds/02.md index 996f2ce..230ecad 100644 --- a/buds/02.md +++ b/buds/02.md @@ -47,7 +47,7 @@ Servers MAY reject an upload for any reason and should respond with the appropri Servers MAY accept an authorization event when uploading blobs and should perform additional checks 1. The `t` tag MUST be set to `upload` -2. MUST contain at least one `x` tag matching the sha256 hash of the blob being uploaded +2. MUST contain at least one `x` tag matching the sha256 hash of the body of the request Example Authorization event: diff --git a/buds/05.md b/buds/05.md new file mode 100644 index 0000000..2ad9851 --- /dev/null +++ b/buds/05.md @@ -0,0 +1,45 @@ +# BUD-05 + +## Media optimization endpoints + +`draft` `optional` + +Defines the `PUT /media` endpoint for processing and optimizing media + +## PUT /media + +The `PUT /media` endpoint MUST accept binary data in the body of the request and MAY use the `Content-Type` and `Content-Length` headers to get the MIME type and size of the media + +The server should preform any optimizations or conversions it deems necessary in order to make the media more suitable for distribution + +The endpoint MUST respond with a `2xx` status and a [blob descriptor](./02.md#blob-descriptor) of the new processed blob + +Servers MAY reject media uploads for any reason and should respond with the appropriate HTTP `4xx` status code and an error message explaining the reason for the rejection + +### Upload Authorization + +Servers MAY require an `upload` [authorization event](./02.md#upload-authorization-required) to identify the uploader + +If a server requires an `upload` authorization event it MUST preform all the checks outlined in the [`/upload`](./02.md#upload-authorization-required) endpoint + +## HEAD /media + +Servers MUST respond to `HEAD` requests on the `/media` endpoint in a similar way to the `HEAD /upload` endpoint defined in [BUD-06](./06.md) + +## Limitations + +This endpoint is intentionally limited to optimizing a single blob with the goal of making it easier to distribute + +How the blob is optimized is the sole respirability of the server and the client should have no say in what optimization process is used + +The goal of this endpoint is to provide a simple "trusted" optimization endpoint clients can use to optimize media for distribution + +If a longer optimization or transformation process is needed, or if the client needs to specify how a blob should be transformed. there are other tools and protocol that should be used. + +## Client Implementation + +Clients MAY let a user selected a "trusted processing" server for uploading images or short videos + +Once a server has been selected, the client can upload the original media to the `/media` endpoint of the trusted server and get the optimized blob back + +Then optionally the client can ask the user to sign another `upload` authorization event for the new optimized blob and call the `/mirror` endpoint on other servers to distribute the blob