CraysBouquet
Bouquet is the practical control room for a part of Nostr most people only notice when it breaks: the media servers behind your pictures, PDFs, audio files and video links.
The boring question that matters
Nostr makes identity and publishing feel light. You sign an event, send it to relays, and another client can read it without asking one company for permission. But media is not light. Images, videos, audio files, PDFs and thumbnails do not fit neatly inside that tiny signed event. They live on HTTP servers, CDNs, paid storage, hobby servers, public uploaders and half-remembered domains that may or may not still exist when a reader opens your post six months later.
That is the unglamorous corner Bouquet walks into. It asks the question most people skip: where do your files actually live, and can another Nostr client find them if the first URL dies? For a casual meme, that may sound fussy. For a creator, musician, writer, event organizer or builder shipping product screenshots, it becomes basic hygiene. If your Nostr presence depends on media, your media servers are part of your publishing stack.
Bouquet is useful because it refuses to turn that stack into folklore. It gives you a product surface for the storage layer. You can see servers, upload files, browse what is already there, move content between places and publish your preference list on Nostr. That sounds almost too practical to be interesting. In this ecosystem, practical is exactly the interesting part.
What Bouquet actually does
The short public description is accurate: Bouquet is a personal manager for Blossom media servers. NostrApps lists the core jobs plainly: upload files, download files, manage your list of media servers, broadcast that list on Nostr, sync files between servers and browse files on your media servers. Read that list slowly and you can see the shape of the product. Bouquet is not trying to be your timeline, your long-form editor or your image gallery. It is the drawer where the handles for your media infrastructure live.
A normal user flow looks like this: you connect a Nostr identity, choose or add media servers, upload a file, inspect the resulting metadata, and decide whether that file should exist on one server or be mirrored elsewhere. If you publish your Blossom server list, other clients can discover where you prefer to host your blobs. If you still use a NIP-96 file server, Bouquet keeps that older preference list in the conversation too.
The app bundle also shows a practical set of known server options and examples, including services such as blossom.primal.net, cdn.nostrcheck.me, cdn.satellite.earth, files.v0l.io and nostr.build. Do not read that as an endorsement of any one host. Read it as the product telling you the truth: Nostr media is plural. You may use one server for convenience, another for redundancy, and a third because a specific client or community already understands it.
The most important feature is not the upload button. It is the server list. Uploading a file to a host is easy. Publishing a machine-readable list of the servers you trust, in a way other clients can discover, is what turns media storage from a one-off upload into part of your portable identity.
Imagine you are publishing a venue announcement. The text note can move across relays, but the poster image may sit on one media domain. If that domain expires, rate-limits your audience, changes its terms or drops old files, the note still exists but the thing people came to see is gone. Bouquet gives you a place to think about that before the failure happens. You can keep a primary host, mirror the same content elsewhere and make your preferred servers visible to the rest of the network.
That is also why Bouquet feels different from a generic uploader. A generic uploader says: give me a file and I will give you a URL. Bouquet says: choose the servers that belong to your Nostr identity, understand what each one can do, and make the list portable. It is closer to a media cockpit than a drag-and-drop box.
The technology under the flowers
The official app runs at bouquet.slidestr.net. The public repository trail points to git.v0l.io/florian/bouquet, and the app shell is a Vite-style web application with a Bouquet icon at /bouquet.png. The package history shows a modern React and TypeScript stack: Vite, React, React Router, TanStack React Query, NDK, NDK Cache Dexie, nostr-tools, blossom-client-sdk, react-pdf, blurhash, p-limit and axios. That tells you what kind of app it is. It is a client-side control panel, not a hidden server that stores your files for you.
NDK matters because Bouquet has to speak Nostr, not just HTTP. The public code imports NIP-07, NIP-46 and private-key signer paths through NDK, uses an NDK cache adapter backed by Dexie, and connects to a default relay set that includes familiar public relays such as relay.damus.io, relay.nostr.band, relay.snort.social, nos.lol, nostr.wine, relay.primal.net and purplepag.es. Again, the exact relay list is less important than the pattern: Bouquet needs relays to read and publish the events that describe your server preferences.
The Blossom side is where the product gets its teeth. Blossom stores files as blobs addressed by SHA-256 hash. BUD-01 defines the basic HTTP behavior for retrieving blobs by hash. BUD-03 defines the user server list as a replaceable Nostr event of kind 10063, with one or more server tags. NIP-B7 then describes how Nostr clients should use Blossom for media, especially by fetching a user's kind 10063 server list when a media URL can no longer be reached from its original host.
Bouquet also cares about NIP-96, the older HTTP file-storage integration. NIP-96 is now marked unrecommended in favor of Blossom, but existing clients and servers still use it. NIP-96 preference events use kind 10096, and Bouquet's code tracks a NIP-96 server list beside the Blossom server list. That is a very real product decision. The ecosystem is not switching storage standards overnight. Bouquet is useful precisely because it stands in the messy transition zone where both protocols matter.
The repository history makes that transition feel concrete. Recent public changes mention pagination for Blossom and NIP-96 list endpoints, improved transfers with retry logic and cancellation, mirror support and a fix around empty SHA-256 values from older server uploads. Those are not brochure features. They are the rough places a real media manager hits when it leaves the demo path. Lists can be paged. Transfers fail. Some servers support listing; some do not. A file can be transformed by a server and still need to be found by its original hash. Bouquet is interesting because it has to handle those ordinary annoyances.
There is a quiet design lesson here for the whole Nostr app landscape. The social layer is only one layer. A mature client has to know where media comes from, how it was signed, whether it can be fetched again, whether a thumbnail is trustworthy, and how to avoid locking the user into one upload service by accident. Bouquet does not solve every piece of that puzzle, but it brings the puzzle onto the screen.
The public trail behind the project
The honest answer to "who is behind Bouquet?" is narrower than a marketing page would like. The public source trail points to the Gitea repository florian/bouquet on git.v0l.io, to the v0l infrastructure family, and to the Slidestr-adjacent deployment at bouquet.slidestr.net. The repository history shows work by Florian, a merge from Quentin for an old-server SHA-256 fix, and later changes around Docker builds, pagination for Blossom and NIP-96 list endpoints, retry logic and transfer robustness.
That is enough to say something useful and not enough to invent a founder story. Bouquet looks like a builder-led tool from the v0l/Slidestr neighborhood of Nostr, built for people who already understand why media storage is becoming a product category. It is not presented as a polished consumer brand with a support desk, pricing page and corporate about section. Treat it like a serious open web tool: powerful, revealing, and worth testing with your own threat model instead of blind trust.
The deploy script in the public package history uses nsite-cli to upload the built dist folder. That detail fits the whole project nicely. Bouquet is a web client for managing portable media infrastructure, and it can itself be published as a static site. The tool and the deployment philosophy are pulling in the same direction.
The lack of a glossy about page is not a defect by itself. Many useful Nostr tools arrive from builders first and brands later, if at all. But it does change how you should read the app. You should look at the repository, the commit history, the servers it suggests, the signing flow and the exact events it publishes. In a protocol world, evidence is better than a slogan. Bouquet gives enough public evidence to treat it as a real project, and enough unfinished surface to remind you that you are using open infrastructure, not a sealed consumer platform.
How to use it without fooling yourself
If you are a creator, start small. Connect with a signer you trust, add a server you actually understand, upload a harmless test file, then open the result from another Nostr client. Look at the URL. Look at the hash. Look at whether Bouquet can list the file later. If the server supports mirroring, try moving the same blob to a second server. Then publish your server list and see whether another tool can discover it. That sequence will teach you more than any abstract argument about decentralization.
Do not confuse portability with privacy. Blossom is designed around content-addressed media, not private vault storage. A file that is public on a media server should be treated as public. If the file contains a face, location, document, private chat screenshot or anything you would regret seeing indexed, think before uploading. Check the server's terms, quotas, retention policy, metadata handling, transformation behavior and deletion support. Keep your originals. Keep a second copy. Media servers are infrastructure, not magic.
If you are a developer, Bouquet is useful as a map of where Nostr media clients are heading. It touches the same themes every serious media client eventually has to face: signer UX, relay discovery, server preference events, hash-based retrieval, upload limits, compatibility with older NIP-96 servers, mirroring and the awkward truth that some popular servers do not expose the same listing features as others. Bouquet makes those constraints visible instead of hiding them behind a pretty upload form.
If you run a community, the app gives you a simple operational ritual. Pick the media servers you trust, test them with small files, document which one is primary, mirror important assets, and check the list every few weeks. That may sound overly careful until you try to recover a missing event flyer, a band photo, a product screenshot or a recorded session from a dead URL. The cost of a small storage routine is low. The cost of losing your media archive is annoying at best and reputation-damaging at worst.
If you are evaluating Bouquet for a business or a serious creator workflow, ask boring questions on purpose. Who operates each server? What happens when you exceed quota? Can you delete? Does the server transform files? Does it strip metadata? Does it support range requests for video? Does it support list endpoints well enough for Bouquet to show your files? Does mirroring preserve the hash you expect? Can another client find the blob from your published server list? These are not edge cases. They are the difference between owning a media workflow and hoping an upload link survives.
The product is niche, but the niche is important. Nostr needs timelines, wallets, signers and search. It also needs tools that help people own the boring layer under the beautiful post. Bouquet is one of those tools. You open it when you are ready to stop treating media as an attachment and start treating it as part of your Nostr identity.
Sources worth opening
This article keeps claims close to the public project trail. Start with these pages when you want to verify Bouquet yourself.
- Official project
- NostrApps listing
- Bouquet source repository
- Bouquet public change history
- Nostr Compass: Blossom Protocol
- BUD-01: server requirements and blob retrieval
- BUD-03: user server list
- NIP-B7: Blossom media
- NIP-96: HTTP file storage integration
- Nostr Development Kit
- NIP-25 reactions
- NIP-27 text note references
- Nostr protocol NIPs repository
- NIP-01 basic protocol flow
- NIP-05 DNS identifiers
- NIP-07 browser signer capability
- NIP-10 text note threading
- NIP-11 relay information document
- NIP-19 bech32 encoded entities
- NIP-44 versioned encryption
- NIP-46 remote signing
- NIP-51 lists and mute lists
- NIP-56 reporting
- NIP-57 lightning zaps
- NIP-65 relay list metadata
