NIP-B7: Blossom media
NIP-B7 explains how Nostr clients should use Blossom media servers and kind 10063 server lists to recover, verify and route content-addressed blobs by SHA-256 instead of relying on one fragile media URL.
Media should 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 should 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 readers 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 a reader, 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 should 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 should 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 should 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.
Direct sources
Use the official file first, then the commit history, implementation references and adjacent standards. NIPs move, and product guidance gets weaker when those source trails are hidden.
