@ Anthony Accioly
2025-03-20 02:37:15
Hey Beave, as always, I welcome your takes. I don't know if your questions are rhetorical or not, but I'll try to answer and comment below, as I was the one who summoned you (despite thinking there are people more qualified than me to do this).
> What is it?
A way for you to upload, store, and serve your photos, videos, etc., now supported by many Nostr clients.
> How does it work?
Just like Nostr, Blossom is a specification/standard. It works at the HTTP level instead of WebSockets and is evolving as we speak. You can find the equivalent of Nostr NIPs (Blossom BUDS) here, along with the supported endpoints: https://github.com/hzrd149/blossom. And yes, this means there are no NIPs for Blossom that I know of, as Blossom is its own thing.
> Is it even worth bothering with?
Only you can answer that. I'm personally using Haven to store and serve my own media on Nostr, so I have a use case to cover. Granted, this can also be done with NIP-96, which is why Vitor is pointing out the competing technologies and possible deprecation path above.
> I don't trust the devs building it [...] stable, simple to set up, easy to use, and most importantly, reliable.
Well, I don't think I'm a reliable dev myself, so everything I'm about to say likely won't help much 🤣. But since I've been using Blossom through Khatru + Haven, it means I've been fixing bugs and keeping an eye on performance and reliability for my own benefit. I'm also working hard on documenting Haven and making it as easy as possible to run. You can basically run docke compose up and get a fully working, all-batteries-included version of Haven with its built-in Blossom server from my repo.
I certainly welcome you to try it and get in touch about any issues you encounter if you are ever curious about it. But this is not my main point... What I'm trying to say is that, like me, there are plenty of devs without grants or VC money, spending a few hundred sats for each sat they receive on Nostr. The way free software advances is by folks using stuff, reporting bugs and eventually getting so annoyed with some things that they decide to fix them themselves. Get enough people involved, each doing their small share of humble, honest work, and suddenly neither I nor anyone else is bigger than the project itself (not even the Linus Torvalds of the world).
--
As for the rest of what you said... I get it. I really do. Nostr has been a learning experience for me as well and not just in a technical sense (learning Go, Nostr, Blossom, and enough about their respective ecosystems so that I could get things working) but more importantly, I'm learning about building things in the open.
Sure, 99% of the software on Nostr wouldn't make the v1 cut if I were "in charge." No tests? Messy architecture and code that you're afraid to refactor without breaking? No consensus on basic functionality? Devs actively breaking each other's software to make a point? Everyone trying to escape the "legacy" stuff to work on self-contained greenfield projects? Sorry, no go buddy. I'm often here complaining to Vitor, Fiatjaf, hzrd149, and others about the gazillion things that never get fixed and that drive me crazy as a user.
Why does Amethyst keep spamming my relays instead of simply sending events to the right place? Why is there no GiftWrapping DM support in clients X, Y, and Z? Why is logging in with Amber so hit-or-miss? And why Nostrudel... and Citrine... and Pokey... and, and, and...
Yet here I am, complaining about all these broken things and about all the improvements devs need to make... I'm doing it here... Today. We are using and shaping Nostr and surrounding tech, with all of its flaws, infighting, bugs, arguments and dead ends happening in public. This imperfect ecosystem, with all its messiness and larger-than-life characters with their unique personalities. Open. In public. Today.
We're complaining about Nostr software that’s already in users' hands. Haven is powering ~10% of Nostr relays if the statistics are to be trusted. Haven didn't exist last August. And if it weren’t for Utxo "rushing" it to release, if it had been built by my own standards, it simply wouldn't have been released. And I don't just mean that we wouldn't have a v1. I mean it would likely still be pre-alpha software in a well-hidden repository, run by maybe five devs for, I don’t know, a couple of years?
By then, Haven might have had the best and most complete test suite, the cleanest code, the best UX, and tons of amazing features, all conveniently packaged and ready to go on 20 different OSes and five different hardware architectures, thanks to a flawless CI pipeline and a well-secured software supply chain. And by then, Haven might have been totally irrelevant, or maybe it wouldn’t have been released at all. I've seen this happen before in projects consuming the kind of budget that all VC investment + grants on Nostr combined couldn't pay for (not a hyperbole by the way; this often happens in massive companies). This is why we need people testing, breaking, and improving these tools in the open... Today!
Am I saying that building software in a more private, well-planned way is bad? Not necessarily. I recommend reading The Cathedral and the Bazaar by Eric Raymond if you're interested in this kind of thing. A lot of what is built on Nostr follows the bazaar model, but there’s certainly some cathedral-style software being built very successfully here too. Depending on what you're building, the cathedral model makes a lot of sense.
However, without trying to kiss any dev asses around here, I’m glad for the bazaar. I understand its values, even when they clash with my own. I hope this makes sense and puts my interest in discussing the merits and flaws of Blossom and NIP-96, as well as the path forward for popular clients like Amethyst in the right context.
These are my two pennies. At this post length, it’s almost a pound. This should have been a long-form article or maybe even a series of articles to begin with. Hopefully, it’s helpful to others. Otherwise, it was just fun to ramble about random stuff.