NIP-B7: Blossom media
Media must not die because one URL breaks
Nostr events can be copied across relays, but media files usually live on HTTP servers. If the one URL in an event goes down, the signed event remains but the image, audio or video disappears. Blossom attacks that problem by addressing blobs by their SHA-256 hash.
NIP-B7 tells Nostr clients how to use Blossom in a Nostr-native way. A user can publish a kind 10063 list of Blossom servers. If a media URL ends in a 64-character hex hash and becomes unavailable, a client can look up the same hash on the user's other Blossom servers.
The client needs to verify that the downloaded bytes match the hash. That is the practical shift: the URL becomes one route to a blob, not the identity of the blob.
Kind 10063 server lists and hash-based recovery
A kind 10063 event lists Blossom servers with server tags. The NIP points people to Blossom BUDs, especially BUD-03, for the server-list behavior. Nostr clients can also use other Blossom endpoints for upload, delete, check and list operations.
When a Nostr client sees a file URL ending in a 64-character hex string, it can treat that as likely SHA-256 content identity. If the original URL fails, the client can try the user's server list and request the same hash path, optionally with the file extension.
NIP-B7 is why NIP-96 is now deprecated. It better matches a content-addressed media world.
Blossom became the media direction in 2025
fiatjaf added NIP-B7 for Blossom interaction in April 2025 through PR #1822. That same day, B7 and B0 were uppercased in the repo. In September 2025, NIP-96 was deprecated in favor of Blossom, making B7 a central media-storage page for the current NIP atlas.
The ecosystem around Blossom is visible. hzrd149's Blossom repository describes blobs stored simply on media servers. Route96 supports Blossom and NIP-96. Nostr Learn Blossom demonstrates uploads, deletion and server selection with examples such as blossom.band, nostrcheck, nostr.download, Primal and Satellite.
For you, the point is not the brand name. It is the move from location-addressed media to content-addressed media.
Verify bytes, then choose routes
A client needs to read the user's kind 10063 server list, try alternate Blossom servers when a hash-based URL fails and verify SHA-256 before trusting the file. It can still show thumbnails, imeta and NIP-94 fields, but the hash check is the foundation.
Media upload flows needs to let users choose their servers and understand whether files are public. Blossom makes retrieval more resilient; it does not make public media private.
Server operators needs to document limits, deletion behavior and abuse policy because media hosting carries real cost.
Resilient media is still public media
Content-addressed storage helps availability, but it can also make unwanted media easier to mirror. Clients and servers need reporting, deletion and policy controls.
Users may also misunderstand hash verification as trust in the content. A matching hash only proves the bytes are the bytes referenced. It says nothing about safety, legality or accuracy.
Read NIP-B7 in the wild
NIP-B7 is Blossom, a media-storage pattern close to Nostr but separate from relays. Relays carry signed events; Blossom servers handle larger bytes.
That separation keeps the protocol cleaner and makes the storage bill visible. It also means availability, moderation, hash verification and self-hosting choices belong in the UI.
What changes when you actually use it
For you, NIP-B7: Blossom is felt when a post becomes a durable object: article, file, image, video, audio, bookmark, wiki entry or source reference. The question is whether the work still makes sense after one app, host or relay disappears. The concrete pieces kind 10063, draft, kind:10063 decide whether the object carries enough context to survive.
What changes for builders and operators
For builders, NIP-B7: Blossom is context preservation. Store enough title, tag, author, hash, URL, media, preview and reference material that another interface can rebuild the object. If your feature depends on a private database to make sense, the NIP is not doing the portability work yet.
What the official file makes concrete
The official file is organized around More complex interactions. Inspect kind 10063, draft, kind:10063 because these are the pieces most likely to surface as product behavior.
NIP-B7: Blossom protects context. Titles, media, hashes, source links, timestamps and references decide whether work survives beyond one app.
Where it breaks
The failure mode in NIP-B7: Blossom is link rot with a nice interface. Media disappears, metadata lies, source URLs change, hashes are missing or an article loses its addressable identity. The page needs to make durability part of the feature, not an afterthought.
Where this appears outside the markdown
In the ecosystem, NIP-B7: Blossom is part of the creator and archive layer. It decides whether writing, media, files, bookmarks, wiki material or source references remain understandable after the first app disappears. That is why media standards need to talk about storage, provenance and recovery, not only presentation.
The nearby-standard trap
The nearby-standard trap in NIP-B7: Blossom is flattening every creative object into a note with a link. Articles, videos, files, torrents, highlights, images, wiki entries and bookmarks carry different metadata and storage pressure. Read NIP-01 and the adjacent source links so the product does not throw away the part that made the object portable.
Language that keeps the feature honest
Good product copy for NIP-B7: Blossom names the object and the storage. It says article, file, image, video, bookmark, wiki page, torrent, highlight or podcast episode, then tells you where the signed metadata ends and where external hosting begins.
What this page does not promise
NIP-B7: Blossom does not guarantee that published work survives forever. It can carry richer metadata, hashes, references or addressability, but files still need hosts, relays still need retention, and clients still need to render the object faithfully. Treat the NIP as the signed map of the work, then check where the actual bytes, previews and source links live.
Read it as a field test
Start NIP-B7: Blossom with the object you want to keep: article, file, media, bookmark, repository, torrent, wiki entry or podcast episode. Then trace which parts are signed, which parts are hosted, and which parts another client can reconstruct from kind 10063, draft, kind:10063. That is the difference between portable publishing and a pretty link preview.
Where the standard earns trust
The source links give you places to test the interpretation in public: Blossom repository, BUD-03, Route96, Nostr Learn Blossom. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-B7 source is the anchor for exact wording, and NIP-B7 commit history shows how that wording moved over time. The strongest secondary clues here are Blossom repository, BUD-03, Route96. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-B7: Blossom: first the human promise, then kind 10063, draft, kind:10063, then the implementation record, then the real-world failure case. That order keeps NIP-B7 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Where do the signed metadata and the actual media or file bytes part ways?
- Can the object still be identified by hash, address, title, author and source if the first URL breaks?
- Does a second client know enough from
kind 10063,draft,kind:10063to render the work without private context?
What to verify before you rely on it
- Find
kind 10063,draft,kind:10063in the official file and check where the UI exposes the same concept. - Read NIP-01 and the adjacent source links as context before treating NIP-B7 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-B7: Blossom in that order: Official NIP-B7 source for the current wording; NIP-B7 commit history for the change record; Blossom repository, BUD-03, Route96 for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
