-
@ miljan
2025-05-05 15:26:08I remember the first gathering of Nostr devs two years ago in Costa Rica. We were all psyched because Nostr appeared to solve the problem of self-sovereign online identity and decentralized publishing. The protocol seemed well-suited for textual content, but it wasn't really designed to handle binary files, like images or video.
The Problem
When I publish a note that contains an image link, the note itself is resilient thanks to Nostr, but if the hosting service disappears or takes my image down, my note will be broken forever. We need a way to publish binary data without relying on a single hosting provider.
We were discussing how there really was no reliable solution to this problem even outside of Nostr. Peer-to-peer attempts like IPFS simply didn't work; they were hopelessly slow and unreliable in practice. Torrents worked for popular files like movies, but couldn't be relied on for general file hosting.
Awesome Blossom
A year later, I attended the Sovereign Engineering demo day in Madeira, organized by Pablo and Gigi. Many projects were presented over a three hour demo session that day, but one really stood out for me.
Introduced by hzrd149 and Stu Bowman, Blossom blew my mind because it showed how we can solve complex problems easily by simply relying on the fact that Nostr exists. Having an open user directory, with the corresponding social graph and web of trust is an incredible building block.
Since we can easily look up any user on Nostr and read their profile metadata, we can just get them to simply tell us where their files are stored. This, combined with hash-based addressing (borrowed from IPFS), is all we need to solve our problem.
How Blossom Works
The Blossom protocol (Blobs Stored Simply on Mediaservers) is formally defined in a series of BUDs (Blossom Upgrade Documents). Yes, Blossom is the most well-branded protocol in the history of protocols. Feel free to refer to the spec for details, but I will provide a high level explanation here.
The main idea behind Blossom can be summarized in three points:
- Users specify which media server(s) they use via their public Blossom settings published on Nostr;
- All files are uniquely addressable via hashes;
- If an app fails to load a file from the original URL, it simply goes to get it from the server(s) specified in the user's Blossom settings.
Just like Nostr itself, the Blossom protocol is dead-simple and it works!
Let's use this image as an example:
If you look at the URL for this image, you will notice that it looks like this:blossom.primal.net/c1aa63f983a44185d039092912bfb7f33adcf63ed3cae371ebe6905da5f688d0.jpgAll Blossom URLs follow this format:
[server]/[file-hash].[extension]The file hash is important because it uniquely identifies the file in question. Apps can use it to verify that the file they received is exactly the file they requested. It also gives us the ability to reliably get the same file from a different server.
Nostr users declare which media server(s) they use by publishing their Blossom settings. If I store my files on Server A, and they get removed, I can simply upload them to Server B, update my public Blossom settings, and all Blossom-capable apps will be able to find them at the new location. All my existing notes will continue to display media content without any issues.
Blossom Mirroring
Let's face it, re-uploading files to another server after they got removed from the original server is not the best user experience. Most people wouldn't have the backups of all the files, and/or the desire to do this work.
This is where Blossom's mirroring feature comes handy. In addition to the primary media server, a Blossom user can set one one or more mirror servers. Under this setup, every time a file is uploaded to the primary server the Nostr app issues a mirror request to the primary server, directing it to copy the file to all the specified mirrors. This way there is always a copy of all content on multiple servers and in case the primary becomes unavailable, Blossom-capable apps will automatically start loading from the mirror.
Mirrors are really easy to setup (you can do it in two clicks in Primal) and this arrangement ensures robust media handling without any central points of failure. Note that you can use professional media hosting services side by side with self-hosted backup servers that anyone can run at home.
Using Blossom Within Primal
Blossom is natively integrated into the entire Primal stack and enabled by default. If you are using Primal 2.2 or later, you don't need to do anything to enable Blossom, all your media uploads are blossoming already.
To enhance user privacy, all Primal apps use the "/media" endpoint per BUD-05, which strips all metadata from uploaded files before they are saved and optionally mirrored to other Blossom servers, per user settings. You can use any Blossom server as your primary media server in Primal, as well as setup any number of mirrors:
## ConclusionFor such a simple protocol, Blossom gives us three major benefits:
- Verifiable authenticity. All Nostr notes are always signed by the note author. With Blossom, the signed note includes a unique hash for each referenced media file, making it impossible to falsify a media file and maliciously ascribe it to the note author.
- File hosting redundancy. Having multiple live copies of referenced media files (via Blossom mirroring) greatly increases the resiliency of media content published on Nostr.
- Censorship resistance. Blossom enables us to seamlessly switch media hosting providers in case of censorship.
Thanks for reading; and enjoy! 🌸