No, you cannot have both. I sounded my concerns multiple times, and by now I gave up. I put in almost 3 years of my life to try and make it pleasant (as much as I can) but nobody wants it. I’d rather spend my time on things I or others appreciate.
Discussion
i understand all of the work you've done and i greatly appreciate you Fishcake. however, i don't think your customer wants to hear that it just won't work. there has to be something that can be done to make this easier for people.
1. User selects video in client
2. Client uploads to blossom server
3. Server returns: original hash immediately
4. User can publish note right away with original hash
5. Server transcodes in background
6. Later: client polls or server webhooks when derivatives ready
7. Client prompts user (or auto-signs if authorized) the derivative manifest
8. Manifest event published, linking original → derivatives
why wouldn't that work?
> i don't think your customer wants to hear that it just won't work
What's the poor guy supposed to do? Nothing supports what's being asked of him. And he can't just throw something out there and be like "yo, nostr, support this!".
i think that's actually what he should do. that's how most things get built around here. build a custom NIP and BUD for it if need be and make it work. work with Primal, they have a good relationship and working partnership on mirroring already. it's in Primal's best interest to do this too so that they can support creators. i think it's solvable if you want to solve it.
It's solvable over the course of, what, two years, with a big lobbying effort, intense pushback from those who disagree with the solution and prefer another one, and painfully slow coffee-drip client propagation. (Don't forget Primal, which you mentioned, is still on NIP-04).
And that's assuming it gets adopted at all.
Async server-side transcoding in a verifiable hash environment in a system that doesn't have any sort of holding pen (because there is no central authority to hold stuff) is just really complex. Remember when MLS was supposed to take just some months and have libraries that'd make it easy for any NIP01 client to integrate, and by now we'd all be enjoying MLS groups in our Damusus and our Primals?
Look this stuff is years and years, I'll call anyone's bluff that says this is just a "few months" of friendly zoom calls and clacking around on the keyboard.
agree. nostr is permissionless. make the nip & publish it, get feedback. if the feedback isnt valid or you dont get feedback, build the thing anyway.
sounds to me like he's exhausted
three years of work he put in to this direction, now everything moves in a hash direction and, and if we're being honest to get any sort of hash-based decentralised transcoding system working for users protocol wide (or anything even near protocol wide) is another two or three years.
building on nostr is fast. propagation on nostr is incredibly slow.
At least make the implementation before the nip. This is why I don't believe in nips.
the guy literally built the implementation for this already, over years. then from another angle others pushed a different logic that makes his implementation not feasible.
this is fine, both solution-types (global hash vs. managed service) have pros and cons. His way was WAY easier for transcoding. The Blossom way you have to prove, with hashes, that all of the transcoded variants are the "same thing" (even though in file terms they are not at all the same thing), and in a way that someone is going to pay for (the 'proving these variants are from the same original' part is gonna make it super expensive), etc.
to say, hey, yes your way would have been way easier, but anyway, kindly start again on another years-long journey, on a path with obstacles that you didn't ask for, with extra costs that you didn't ask for, and sure, nostr might do an end-run around you once again, but this is the nostr way .. i dunno, i feel for the guy.
Same with users. I feel his pain deeply. I’ve managed to stick around because of a lot of help from my parents and many developers around the world who have been extra kind and patient with me and my team. But Nostr needs basic stability across a few good solutions first and it needs to stop leaving half finished projects on the table and moving on to something new. I was told blossom servers would not work 6 months ago but numerous developers kept pushing me towards blossom - - all only to hear, again, blossom won’t likely work long term for media protection. I keep saying it but if developers would actually listen to users, maybe we could get some traction here.
Yes it's tough. Nostr maybe needs a reboot of sorts.
The issue with Blossom for transcoding is that unless you have rock-solid proof that all the transcoded renditions (720, 1080, etc.) are from the same high-res original then you cannot put any sort of cryptographic stamp of authenticity on the whole set.
If there is even a small amount of trust involved then anyone can potentially sneak anything into any rendition and make a mockery of your cryptographic stamp of authenticity for the set, whatever that stamp happens to be. So maybe a little porn scene snuck into the 720p rendition. If that's possible at all then you cannot stamp.
And for transcoding we’re talking 5 or so renditions per source, often more.
This act of proving all the renditions come from the same original is possible but very expensive and very complex. (Involves trusted execution environments and a bunch of other stuff.) And hard to nostr-ize too.
But for Blossom, it's a "this thing is definitely this thing" hashing protocol. For users one video is one video, they don’t see it as multiple transcoded renditions, so you can't just go hashing one by one. Either you stamp the whole set as a 'single thing' or you stamp nothing.
If we say "well then for transcoded videos we'll just go on trust like at YouTube" then that's fine, we go on trust, but then what is the point of Blossom? For that you only need managed services, like what nostr.build was working on.
Creators shouldn't have to worry about any of this.