Blossom (Media Storage)

Blossom is a protocol for storing binary media, called blobs, on simple HTTP servers that are independent of Nostr relays. It exists because relays are designed to store and forward small signed text events, not large images, audio, or video. Stuffing megabytes of media into events would bloat relay databases, slow synchronization, and force every relay operator to become a file host. Blossom moves the heavy bytes off the relay layer entirely and addresses each file by the SHA-256 hash of its contents, so Nostr clients can reference media in a portable, verifiable way while relays keep doing what they are good at.

Content-addressed blobs

Every blob is identified by the SHA-256 hash of its bytes. The core retrieval endpoint is GET /<sha256>, served from the root of the server's domain, which returns the raw blob. Because the address is the hash, a client can fetch the same file from any Blossom server and verify it is bit-for-bit correct before displaying it. That single design decision makes storage interchangeable: if one server disappears, goes offline, or starts censoring, the identical blob can be retrieved from any other server that holds a copy, and the URL embedded in a note can be rewritten to point elsewhere without breaking verification. Servers are expected to send permissive CORS headers so web clients can fetch across origins, and they may support optional niceties such as file extensions appended to the hash, HTTP range requests for streaming, and a Sunset header advertising when a blob may become unavailable.

Authorization with signed events

Uploads, deletions, and listing operations are gated by authorization events: signed Nostr events of kind 24242 whose t tag names a verb such as upload, get, list, delete, or media. The server checks the signature against the user's pubkey before honoring the request. This is a quietly powerful pattern: the same keypair that signs your notes also authorizes your media operations, so there is no separate account system, no password database, and no email-based identity to leak. Media hosting inherits the identity model of the protocol itself. See Nostr Event Kind for how event types like 24242 are allocated.

Mirroring and media survival

Because blobs are content-addressed, mirroring is trivial and trust-free. A client or a background service can copy a user's blobs to two or three independent Blossom servers, and any consumer can verify each copy against the same hash. Some clients do this automatically at upload time, writing the file to multiple servers so a single host failure never breaks old posts. Contrast this with the centralized web, where an image lives at exactly one URL controlled by one company, and when that company deletes it, rebrands, or shuts down, a decade of embedded media rots.

Why it matters for sovereignty

For sovereign users, Blossom means your media is not locked to one provider and can survive any single host, the same way your notes can survive any single relay. You can run your own Blossom server on hardware you own, next to the node and relay you already operate, and your public history stays reachable for as long as at least one mirror exists. The protocol is deliberately boring: plain HTTP, plain hashes, plain signed events. That boringness is the feature. It keeps the barrier to self-hosting low and keeps the storage layer swappable, so no media host ever accumulates the kind of leverage that platform image CDNs hold over the legacy social web. Blossom is one more layer of the stack that decentralizes cleanly: identity stays in your keys, text stays on relays you choose, and media stays on servers you can replace at will.