A signed status event is often only the beginning of a workflow. The useful material may be a report, an image, a recording or another supporting file. Readers need to know that the bytes they retrieved are the bytes the publisher referenced.

DamageBDD's Blossom implementation exposes blobs through their SHA-256 hashes while storing the bytes through its IPFS backend. A descriptor retains the IPFS CID as additional metadata. Nostr-signed authorization controls uploads and deletion of ownership claims.

For a Nostr client developer or operator, this is a concrete integration to try: upload a non-sensitive fixture, retrieve it through its hash address, and independently verify the digest. This gives you a useful first result without requiring a complete social client or knowledge workflow.

Suppose a signed event announces a report and includes an attachment link. A filename such as report-final.pdf is convenient for people, but it does not identify one exact version. A SHA-256 digest lets the recipient check whether the downloaded bytes match the attachment the event referenced.

Blossom uses that digest as the blob's public identity. DamageBDD's backend also records an IPFS content identifier (CID), which locates the stored representation in its IPFS workflow. The Blossom hash and IPFS CID serve related purposes but are not interchangeable identifiers.

The application still decides which signed event authorises the association and how long the file should remain available. Hash verification checks byte identity; storage operations and retention policy keep the bytes retrievable.

The module describes support for core BUD-01, BUD-02, BUD-06, BUD-11 and BUD-12 operations. The table records the handlers found in source, not a certification of interoperability with every Blossom client or extension.

The routes are registered by damage_app with the root blob catch-all last, so existing application routes take precedence. Deployment hostnames, TLS, reverse-proxy settings and enabled optional operations still need to be established on the server being integrated.

The verifier handles kind-24242 Nostr authorization events. It checks event shape, public key, creation time, expiration, action, applicable server/hash scope and signature. Parsing and tag sizes are bounded. The implementation accepts standard and URL-safe Base64 encodings, with or without padding, for the transport wrapper.

The upload path enforces declared and actual transfer constraints, computes SHA-256 and checks the authorization's applicable hash scope before persisting the object and claim. This makes useful refusal cases available for a client pilot: wrong action, expired event, mismatched bytes and oversized upload.

The source defaults allow up to 64 MiB per upload, with a 256 MiB absolute ceiling and configurable request limits. The actual server configuration should be read and tested before relying on those defaults. There is no throughput or concurrent-client benchmark from this review.

The shared NIP-96/Blossom store keys objects by SHA-256 and uses source-scoped ownership keys. Removing a Blossom claim does not silently remove a separate NIP-96 claim on the same object. This is a useful boundary when multiple protocol surfaces use the same stored bytes.

The store uses DETS for its metadata. The HTTP handler checks storage results before returning a successful upload response. Retention and failure recovery still depend on the configured metadata store, IPFS backend and their operating procedures. A CID is a byte reference, not an availability promise.

Deletion removes the relevant claim. Unpinning after removal of the last owner is separately controlled by blossom_unpin_on_delete and defaults to false. Even when enabled, unpinning is not a claim that all cached or mirrored copies have disappeared.

A proposed workflow can attach an uploaded object's digest to a signed event and retain that association with a DamageBDD report or ECAI record. A consumer can then compare the retrieved file's hash with the expected value. The application must define which event or report authorises that association.

Upload authorization does not make later blob retrieval confidential. For private documents, establish encryption and access policy before using a publicly readable endpoint. ECAI's private index does not automatically ingest or protect a Blossom upload; it accepts prepared records through its own permissioned interface.

Use a small public fixture with a locally computed digest. Exercise preflight, upload, HEAD, full download and a range request. Verify returned bytes, then repeat with bad authorization and mismatched content. Test two claimants on one object and confirm that deleting one claim leaves the other intact.

Restart the configured services and repeat retrieval. Record the client version, server revision, active limits, storage policy and exact outcomes. The result should be a repeatable client integration report, not simply one successful HTTP response.

• Blossom HTTP operations and limits
• Signed authorization validation
• Shared object and ownership store
• Request rate limits
• Application route registration

The BUD labels in this article describe the handler's stated operations. No live client-conformance, upload or retention test was run for this update. Record the client version and exact outcomes when evaluating interoperability.

• Retain selected signed event records
• Understand the separate private-index boundary
• Turn an integration check into an acceptance record
• Choose a first workflow