mirror of
https://github.com/hzrd149/blossom.git
synced 2025-12-08 14:58:49 +00:00
update wording to allow authorization events to include multiple x tags
This commit is contained in:
12
buds/01.md
12
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)
|
||||
|
||||
|
||||
10
buds/02.md
10
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:
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
10
buds/04.md
10
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)
|
||||
|
||||
Reference in New Issue
Block a user