Nostr Web Client

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.

Reply to this note

Please Login to reply.

Discussion

Ainsley Costello 3d ago 💬 1

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.

JOE2o 3d ago

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.