try_upload in rust/src/nostr/blossom.rs builds the upload URL as {server}/{sha256} (a PUT to the blob's own hash path), but BUD-02 defines the upload endpoint as PUT /upload — the server computes the sha256 itself from the request body, it isn't part of the path. Confirmed against the current spec: https://github.com/hzrd149/blossom/blob/master/buds/02.md, and against the spec's own commit history, PUT /upload has been the defined endpoint since May 2024 — well before this code was written in #91, so this isn't a case of the spec changing after the fact.
The code's own doc comment misattributes this too: it says "Uses PUT /{sha256} per BUD-01", but BUD-01 defines no PUT endpoint at all — only GET / for retrieval. Neither BUD actually describes a PUT to the hash path.
Retrieval (download_blob, GET /) is correct per BUD-01 — this only affects the upload path.
Against a Blossom server that implements the spec strictly, this upload will fail (404/405), silently breaking file attachments.
Impact today: none reachable by users. send_file/download_attachment (the Rust functions that would trigger this) aren't wired to any Dart screen yet — see the open items tracked in #122 (T079/T080/T081). This bug is real but dormant; it needs fixing before that UI wiring lands, not urgently before then.
Found while verifying the BUD claims added in #123 — flagged by @ermeme's review there.
Fix: change the upload request in try_upload to PUT {server}/upload with the blob bytes in the body, per BUD-02. The Kind-24242 auth event construction (t: upload, x: , expiration) already looks correct and shouldn't need to change.
try_upload in rust/src/nostr/blossom.rs builds the upload URL as {server}/{sha256} (a PUT to the blob's own hash path), but BUD-02 defines the upload endpoint as PUT /upload — the server computes the sha256 itself from the request body, it isn't part of the path. Confirmed against the current spec: https://github.com/hzrd149/blossom/blob/master/buds/02.md, and against the spec's own commit history, PUT /upload has been the defined endpoint since May 2024 — well before this code was written in #91, so this isn't a case of the spec changing after the fact.
The code's own doc comment misattributes this too: it says "Uses PUT /{sha256} per BUD-01", but BUD-01 defines no PUT endpoint at all — only GET / for retrieval. Neither BUD actually describes a PUT to the hash path.
Retrieval (download_blob, GET /) is correct per BUD-01 — this only affects the upload path.
Against a Blossom server that implements the spec strictly, this upload will fail (404/405), silently breaking file attachments.
Impact today: none reachable by users. send_file/download_attachment (the Rust functions that would trigger this) aren't wired to any Dart screen yet — see the open items tracked in #122 (T079/T080/T081). This bug is real but dormant; it needs fixing before that UI wiring lands, not urgently before then.
Found while verifying the BUD claims added in #123 — flagged by @ermeme's review there.
Fix: change the upload request in try_upload to PUT {server}/upload with the blob bytes in the body, per BUD-02. The Kind-24242 auth event construction (t: upload, x: , expiration) already looks correct and shouldn't need to change.