Blossom is the missing media-storage chapter many Nostr explanations skip. It is not a social relay and it is not a new feed. A Blossom server is an HTTP blob server for file bytes, while relays remain the place where signed Nostr events are published, discovered and indexed.
The short answer
Blossom means blobs stored simply on media servers. In normal language: a Blossom server stores binary files - images, videos, PDFs, audio, encrypted archives, thumbnails or other file bytes - and makes them available through HTTP URLs.
The core rule is content addressing. A blob is identified by the sha256 hash of the exact bytes. That hash is the stable handle. The URL is just one place where those bytes can be fetched. If the same file is mirrored to another server, the hash should still point to the same content.
That is why Blossom matters for Nostr. Nostr relays are good at signed events, subscriptions, author identity, conversations, timestamps and discovery. They are not the right place for heavy media bytes. Blossom moves the bytes out to file servers while the Nostr event keeps the social and cryptographic context.
- Relay. Stores and serves signed Nostr events over WebSockets.
- Blossom server. Stores and serves file bytes over HTTP.
- Nostr event. Says who published, what file is referenced and how to verify or find it.
- sha256 hash. Lets clients verify that fetched bytes match the expected file.
How one upload works
A client starts with a file. Before upload it can compute the sha256 hash locally. It then chooses a Blossom server, often from the user's BUD-03 server list or from app defaults. If the server requires authorization, the client asks the user's signer for a short-lived Nostr authorization event that scopes the action.
The upload itself is HTTP, not a relay write. BUD-02 defines `PUT /upload`, where the request body is the binary data. A successful server response returns a blob descriptor: public URL, sha256 hash, size, MIME type and upload timestamp. If the server already has the blob, it can return the existing descriptor instead of storing duplicates.
Only after that does the client publish to Nostr relays. The Nostr event can be a normal note, a long-form article, a profile event, a marketplace event, a NIP-94 file metadata event or another app-specific event. That event carries or references the URL, hash, MIME type, dimensions, alt text, fallback sources or imeta-style tags, depending on the client and standard used.
- 1. Prepare. Client reads the file and computes its hash.
- 2. Authorize. Signer creates a scoped Blossom auth event when the server requires it.
- 3. Upload. Client sends the bytes to a Blossom HTTP endpoint.
- 4. Describe. Server returns the URL, hash, size, type and timestamp.
- 5. Publish. Client posts a signed Nostr event to relays with the file reference.
- 6. Fetch. Other clients read the event from relays and fetch the bytes from Blossom.
Where relays fit
Relays still do the Nostr work. They receive signed events, apply relay policy, answer subscriptions and help other clients discover that a file exists. A relay can index the tags, author, event kind, created_at time and conversation context around a file reference.
The relay does not need to download or host the image. It can simply store the event that says, in effect: this pubkey signed this post, this file URL or hash is attached, here are the tags and here is the signature. The media bytes live elsewhere.
This separation makes the network more realistic. Relay operators can manage event spam, paid relay access, local graph behavior and archive policy. Blossom operators can manage storage quota, bandwidth, file moderation, malware scanning, media optimization, deletion policy, payments and mirroring.
- Relays answer. Who signed this? Where is the event? Which tags and replies connect to it?
- Blossom answers. Where are the bytes? What hash do they have? Can this user upload, delete or mirror them?
- Clients combine. Read events from relays, then fetch media through HTTP and verify what they can.
User server lists
BUD-03 defines a replaceable Nostr event, kind `10063`, where a user can advertise the Blossom servers they trust or use. The event contains `server` tags with full server URLs. The order matters because clients should treat the first servers as the most reliable or trusted.
This is the media-storage cousin of relay lists. A relay list helps clients know where to read or write events for a user. A Blossom server list helps clients know where that user's blobs may live, where uploads should go and where missing files can be recovered.
The powerful part is recovery. If a post contains an old URL and that URL no longer works, a client can extract the 64-character hash from the URL, fetch the author's kind `10063` server list from relays, then try each Blossom server for the same hash. If a mirror exists, the file can still load even when the original domain is gone.
- Kind 10063. A replaceable Nostr event that advertises a user's Blossom servers.
- Server tags. Each tag points at a Blossom server URL.
- Ordered trust. Clients should try preferred servers first.
- Recovery. The same hash can be found on mirrors when one URL disappears.
NIP-94 and NIP-96
NIP-94 and Blossom solve different parts of the same problem. NIP-94 defines a file metadata event, kind `1063`, with tags such as URL, MIME type, sha256 hash, original hash, size, dimensions, thumbnail, preview, alt text and fallback sources. It is an event format relays can store.
Blossom is the storage and serving side. It gives clients a way to put bytes on HTTP media servers, retrieve them by hash and advertise server preferences. A client can use Blossom to store a file and NIP-94 to publish rich metadata about it through relays.
NIP-96 is adjacent: it defines an HTTP file storage API intended for use with Nostr clients, including discovery through `/.well-known/nostr/nip96.json`. The useful way to explain it in our archive is: NIP-96 and Blossom both keep files out of relays, but Blossom puts stronger emphasis on hash-addressed blobs, BUD documents, user server lists and Nostr authorization.
- NIP-94. Metadata event for describing files inside the Nostr event graph.
- Blossom. HTTP blob storage and retrieval by content hash.
- NIP-96. Another Nostr-oriented HTTP file-storage API.
- route96. A real implementation reference that touches Blossom and NIP-96 territory.
Authorization and security
A public Blossom URL is not privacy. If the URL or hash is known, clients should assume the blob can be fetched unless the server adds access controls. For private records, private media, member documents or wallet-adjacent material, the right pattern is to encrypt before upload and only publish safe metadata.
BUD-11 defines Nostr authorization tokens. These are signed events of kind `24242` that prove a pubkey allowed an action such as upload, list, delete or media handling. They can include expiration, action tags, server scope and hash scope. This keeps a web app from asking for the user's raw private key while still letting a server verify intent.
Hash verification protects integrity, not secrecy. If the expected sha256 hash is in the event, a client can check that downloaded bytes match the referenced file. That does not stop metadata leaks, EXIF leaks, public URL sharing or server-side moderation. Serious deployments still need file scanning, quotas, takedown process, retention rules and careful UX.
- Encrypt first. Private blobs should be encrypted before upload.
- Verify hash. Clients can compare downloaded bytes against the expected sha256.
- Limit auth. Authorization should be short-lived and scoped to the exact action.
- Strip metadata. Images and documents can leak EXIF or author data.
- Mirror wisely. More availability can also mean wider exposure if the blob is public.
How this fits our infrastructure
For our stack, the clean mental model is simple: a venue or Super Node can run a relay and a Blossom server side by side, but they are separate responsibilities. The relay handles signed member, creator, venue, event, payment, governance and reputation signals. The Blossom server handles media bytes, encrypted originals and large file transfer.
That split is useful for hospitality and creators. Profile images, venue photos, event galleries, creator media, paid content previews, encrypted Safebox records, receipts, award assets and local community files should not bloat relays. They should be referenced by Nostr events and fetched from storage that can be operated, mirrored and paid for deliberately.
A practical Crays node could therefore include a relay, a Blossom server, a signer-friendly auth flow, an indexer, a wallet/payment path and operator tools. Users would not need to know every layer. They should feel one experience: publish, prove, access, pay, recover and move.
- Super Node relay. Event routing, local graph, paid relay policy and signed history.
- Blossom server. Media storage, encrypted blob transfer, quotas and mirroring.
- Signer. Scoped authorization without exposing private keys to the web app.
- Indexer. Search and discovery over event metadata, not raw file hosting.
- Wallet. Paid storage, creator access, zaps or member entitlements.
What to remember
If a reader remembers only one sentence, make it this: relays move and index the signed story; Blossom servers store and serve the heavy bytes. They are complementary infrastructure, not replacements for each other.
That distinction also keeps product language honest. A bad media experience is often not a Nostr failure in the abstract. It can be a storage server, mirror, URL, hash, metadata, relay discovery or client fallback problem. Once we name the layers, we can fix the right layer.
- Do not store big files in relays. Use relays for signed events and discovery.
- Do not trust URLs blindly. Use hashes and fallback sources when possible.
- Do not call Blossom a relay. It is HTTP blob storage for the Nostr ecosystem.
- Do design for recovery. Server lists and mirrors make media less brittle.