add document for returning nip94 tags

buds/02.md

@@ -12,25 +12,13 @@ Defines the `/upload`, `/list` and `DELETE /<sha256>` endpoints
 
 A blob descriptor is a JSON object containing `url`, `sha256`, `size`, `type`, and `uploaded` fields
 
-- `url` A publicly accessible URL to the [BUD-01](./01.md#get-sha256---get-blob) `GET /<sha256>` endpoint (optionally with a file extension)
+- `url` A public facing url this blob can retrieved from
 - `sha256` The sha256 hash of the blob
 - `size` The size of the blob in bytes
 - `type` (optional) The MIME type of the blob
 - `uploaded` The unix timestamp of when the blob was uploaded to the server
 
-Servers MAY include additional fields in the descriptor like `magnet`, `infohash`, or `ipfs` depending on other protocols they support
-
-Example:
-
-```json
-{
-  "url": "https://cdn.example.com/b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553.pdf",
-  "sha256": "b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553",
-  "size": 184292,
-  "type": "application/pdf",
-  "uploaded": 1725105921
-}
-```
+Servers may include additional fields in the descriptor like `magnet`, `infohash`, or `ipfs` depending on other protocols they support
 
 ## PUT /upload - Upload Blob
 
@@ -47,7 +35,7 @@ Servers MAY reject an upload for any reason and should respond with the appropri
 Servers MUST 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 body of the request
+2. MUST contain at least one `x` tag matching the sha256 hash of the blob being uploaded
 
 Example Authorization event:
 

buds/05.md

@@ -1,41 +0,0 @@
-# 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
-
-## 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

buds/08.md

@@ -0,0 +1,33 @@
+# Nostr File Metadata Tags
+
+`draft` `optional`
+
+Describes how a server could return nostr [NIP-94 File Metadata](https://github.com/nostr-protocol/nips/blob/master/94.md) tags from the `/upload` and `/mirror` endpoints
+
+## Returning tags
+
+As described in [BUD-02](./02.md#blob-descriptor) servers MAY add any additional fields to a blob descriptor
+
+Servers MAY return an additional `nip94` field in the [blob descriptor](./02.md#blob-descriptor) from the `/upload` or `/mirror` endpoints
+
+The `nip94` field should contain a JSON object with the keys being the tag names defined in [NIP-94](https://github.com/nostr-protocol/nips/blob/master/94.md)
+
+An example response would look like:
+
+```json
+{
+	"url": "https://cdn.example.com/b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553.pdf",
+	"sha256": "b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553",
+	"size": 184292,
+	"type": "application/pdf",
+	"uploaded": 1725909682,
+	"nip94": {
+		"url": "https://cdn.example.com/b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553.pdf",
+		"m": "application/pdf",
+		"x": "b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553",
+		"size": 184292,
+		"magnet": "magnet:?xt=urn:btih:9804c5286a3fb07b2244c968b39bc3cc814313bc&dn=bitcoin.pdf",
+		"i": "9804c5286a3fb07b2244c968b39bc3cc814313bc"
+	}
+}
+```