nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-09 22:09:06 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

wip: Reconcile NIP-96 and NIP-98 and address implementation challenge

Browse Source
This commit is contained in:
Daniel Roberts 2024-07-26 22:17:56 -05:00
parent 6826f5a52c
commit 2a1945cc7f
2 changed files with 18 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
96.md
View File

@ -84,7 +84,8 @@ See https://github.com/aljazceru/awesome-nostr#nip-96-file-storage-servers.
## Auth ## Auth
When indicated, `clients` must add an [NIP-98](98.md) `Authorization` header (**optionally** with the encoded `payload` tag set to the base64-encoded 256-bit SHA-256 hash of the file - not the hash of the whole request body). When indicated, `clients` must add an [NIP-98](98.md) `Authorization` header.
`clients` SHOULD include either the `payload` tag or the `payload_multipart` tag with the `file` multipart field name included in the digest (`["payload_multipart", "<sha256-of-file>", "file"]`).
## Upload ## Upload

17
98.md
View File

@ -43,12 +43,27 @@ Servers MUST perform the following checks in order to validate the event:
3. The `u` tag MUST be exactly the same as the absolute request URL (including query parameters). 3. The `u` tag MUST be exactly the same as the absolute request URL (including query parameters).
4. The `method` tag MUST be the same HTTP method used for the requested resource. 4. The `method` tag MUST be the same HTTP method used for the requested resource.
When the request contains a body (as in POST/PUT/PATCH methods) clients SHOULD include a SHA256 hash of the request body in a `payload` tag as hex (`["payload", "<sha256-hex>"]`), servers MAY check this to validate that the requested payload is authorized. When the request contains a body (as in POST/PUT/PATCH methods) clients SHOULD include a SHA256 hash of the request body in a `payload` tag as hex (`["payload", "<sha256-hex>"]`) or a SHA256 hash of the relevant fields in a `payload_multipart` tag.
Servers MAY check these to validate that the requested payload is authorized.
If one of the checks was to fail the server SHOULD respond with a 401 Unauthorized response code. If one of the checks was to fail the server SHOULD respond with a 401 Unauthorized response code.
Servers MAY perform additional implementation-specific validation checks. Servers MAY perform additional implementation-specific validation checks.
### The `payload_multipart` tag
The `payload_multipart` tag SHOULD only be sent when authorizing a request with a `Content-Type` of `multipart/form-data`.
A valid `payload_multipart` tag will always consist of 3 or more elements.
The first element is always the tag name, `payload_multipart`.
The second element is the sha256 hash, which is computed over the concatenation of every serialized multipart field, in order.
The third through last elements name the form fields which will be concatenated together to calculate the hash.
`["payload_multipart", "<sha256-hex-of-concatenated-fields>", "<multipart-field-name-0>", ..."<multipart-field-name-N>"]`
The multipart-field-names MUST appear in the same order as they appear in the multipart body.
Repeated field names MUST have corresponding repeated fields in the multipart body.
After a multipart field is added to the sha256 digest, no subsequent multipart-field-name may refer to any multipart field up to and including the one which was just processed (field processing always progresses forward in the request body, never backwards).
## Request Flow ## Request Flow
Using the `Authorization` HTTP header, the `kind 27235` event MUST be `base64` encoded and use the Authorization scheme `Nostr` Using the `Authorization` HTTP header, the `kind 27235` event MUST be `base64` encoded and use the Authorization scheme `Nostr`