update wording to allow authorization events to include multiple x tags

v0l · Aug 27, 2024 · 2de7c0d · 2de7c0d
1 parent 4f650d7
commit 2de7c0d
Show file tree

Hide file tree

Showing 4 changed files with 19 additions and 21 deletions.
diff --git a/buds/01.md b/buds/01.md
@@ -1,8 +1,6 @@
-BUD-01
-======
+# BUD-01
 
-Server requirements and blob retrieval
---------------------------------------
+## Server requirements and blob retrieval
 
 `draft` `mandatory`
 
@@ -24,6 +22,8 @@ Events MUST have the `content` set to a human readable string explaining to the
 
 All events MUST have a [NIP-40](https://github.com/nostr-protocol/nips/blob/master/40.md) `expiration` tag set to a unix timestamp at which the event should be considered expired.
 
+Authorization events MAY have multiple `x` tags for endpoints that require a sha256 hash.
+
 Example event:
 
 ```json
@@ -35,6 +35,7 @@ Example event:
   "created_at": 1708773959,
   "tags": [
     ["t", "upload"],
+    // Authorization events MAY have multiple "x" tags
     ["x", "b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553"],
     ["expiration", "1708858680"]
   ],
@@ -69,6 +70,7 @@ For HTTP `4xx` and `5xx` status codes servers MUST repond with `Content-Type: ap
 The `message` field MUST be human readable and should explain the reason for the error. Optionally servers may include other fields for the client with more information about the error
 
 Example Error response:
+
 ```
 HTTP/2 401
 content-type: application/json; charset=utf-8
@@ -97,7 +99,7 @@ The server may optionally require authorization when retrieving blobs from the `
 In this case the server MUST perform additional checks on the authorization event
 
 1. A `t` tag MUST be present and set to `get`
-2. The event MUST contain either a `server` tag containing the full URL to the server or MUST contain an `x` tag with the sha256 of the blob being retrieved
+2. The event MUST contain either a `server` tag containing the full URL to the server or MUST contain at least one `x` tag matching sha256 hash of the blob being retrieved
 
 If the client did not send an `Authorization` header the server must respond with the appropriate HTTP status code `401` (Unauthorized)
 

diff --git a/buds/02.md b/buds/02.md
@@ -1,8 +1,6 @@
-BUD-02
-======
+# BUD-02
 
-Blob upload and management
---------------------------
+## Blob upload and management
 
 `draft` `optional`
 
@@ -37,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. The `x` tag MUST be present and set to the sha256 hash of the blob
+2. MUST contain at least one `x` tag matching the sha256 hash of the blob being uploaded
 
 Example Authorization event:
 
@@ -103,7 +101,7 @@ Servers MUST accept an authorization event when deleting blobs
 Servers should perform additional checks on the authorization event
 
 1. The `t` tag must be set to `delete`
-2. A `x` tag must be present and set to the sha256 hash of the blob being deleted
+2. MUST contain at least one `x` tag matching the sha256 hash of the blob being deleted
 
 Example Authorization event:
 

diff --git a/buds/03.md b/buds/03.md
@@ -1,8 +1,6 @@
-BUD-03
-======
+# BUD-03
 
-User Server List
--------------------------
+## User Server List
 
 `draft` `optional`
 
@@ -73,6 +71,6 @@ Once the client discovers that the URL `https://cdn.broken-domain.com/b1674191a8
 1. Get the SHA256 has from the URL
 2. Look for the authors server list `kind:10063`
 3. If found, Attempt to retrieve the blob from each `server` listed started with the first
-3. If not found, the client MAY fallback to using a well-known popular blossom server to retrieve the blob
+4. If not found, the client MAY fallback to using a well-known popular blossom server to retrieve the blob
 
 This ensures clients can quickly find missing blobs using the users list of trusted servers.
diff --git a/buds/04.md b/buds/04.md
@@ -1,8 +1,6 @@
-BUD-04
-======
+# BUD-04
 
-Mirroring blobs
----------------
+## Mirroring blobs
 
 `draft` `optional`
 
@@ -16,7 +14,9 @@ Clients MUST pass the URL of the remote blob as a stringified JSON object in the
 
 ```json
 // request body
-{ "url": "https://cdn.satellite.earth/b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553.pdf" }
+{
+  "url": "https://cdn.satellite.earth/b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553.pdf"
+}
 ```
 
 Clients MUST set the `Authorization` header to an upload authorization event defined in [BUD-02](./02.md#upload-authorization-required)