I was just going to comment this. It's a huge 4k file. Here's a web friendly version, signing in at about 33MB 👍
https://v.nostr.build/FXio2VBn3XOyG0o6.mp4
Look into using Handbrake to compress your files for Nostr uploads.
If you have any questions I'd be available to help.
This should be an nostr:npub1nxy4qpqnld6kmpphjykvx2lqwvxmuxluddwjamm4nc29ds3elyzsm5avr7 issue. If there will be a problem seeing it in Nostr - nostr:npub1nxy4qpqnld6kmpphjykvx2lqwvxmuxluddwjamm4nc29ds3elyzsm5avr7 should help the user resolve it before it gets posted.
That's a downside of Nostr's decentralized nature. Centralized platforms have solutions to this, but Nostr so far hasn't fixed this, the work is left to the end user. I've posted about it many times in the past 😂 Support for video compression is included in some clients, Amethyst being one I use.
it's all part of the process of owning your own content. many people don't realize all of the tiny bells and whistles that go into these things though. they'd normally have their content managers or producers or social media teams doing these things for them. if we're trying to empower people, themselves, instead of corporations with these teams of people, then i think we can do better as an ecosystem and work on some of these services for people.
i don't know how nostr.build would do it with blossom files. it would have to be uploaded first, then transcoded, and after the file is finally changed, then signed. that's not a good user experience. they could probably do this for the normal nostr.build uploaded files though since they're not signed.
Yeah I'm pretty sure it would require some work on the client end too. Depending on video size transcoding will take some time. Working that into the note signing flow would need feedback and the client end to be able to get the right file name in the note, etc.
Again. I paid Nostr build $71 a year?! I pay FAR-LESS than that to distribute video through distro-kid. This is not a user issue. This is a Nostr issue.
it's not a nostr issue, this is a nostr.build issue. if you read what i said, you would see that i said two different times that this is something that nostr.build should look into adding for users. i agree that nostr and adjacent services can do a lot to help user experiences.
I disagree. Show me a single nip or client that will allow me to process uploaded media asynchronously. There is none that I am aware of, all need hash to be returned immediately
if you take blossom out of the picture and just use nostr.build then you could do this right?
Absolutely, but what Nostr protocol will support it? I had it ready for rollout a year ago, and was forced to abandon and scrap it thanks to blossom
Only a few clients haven't migrated to Blossom, so we have to figure out how to work in those contraints. You're the expert here... Could we add a BUD spec for derivate blobs? The user uploads, server transcodes, returns derivative hashes, user publishes the manifest.
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.
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.
It is Nostr issue, yes. We are constrained by the sha256 requirements for uploaded content. This means that once you upload something, we cannot change a single bit of that file. Handbrake is a good software that will allow you to produce shareable media.
This. 💯 is my issue as a creator with #nostr
I’ve never thought about this before.
But thank you for committing to this. 🫡
Personally I don't think nostr.build should be on the hook for media compression. But putting the creator on the hook isn't great either because they don't usually know anything about video formats.
A separate caching and compression service is probably the play. Some kind of paid service that clients look to for optimized media. Then the viewer is on the hook, voluntarily employing a middleman to compress, store, and serve content from other providers.
For years, third party scheduling apps for social media have done this for users. Users don’t realize they need to do it. The first person to make a third party scheduling app for Nostr that is like the ones real social media teams use will help Nostr win and become the go-to for normie users—if we ever get them. I keep saying this and will die on this hill.
The problem with Nostr all the things is hash this hash that. So, whatever is uploaded is required to be unchanged. I don’t make the rules, but users live with consequences
Or they just leave 🤷♀️
There needs to be work done on all fronts, not just nostr.builds end. This is something that affects the entire ecosystem, clients, servers, all of it.
Every other platform does this in the back end yes. It would be great for Nostr to see a good video handling system, but it's yet to come about. Supporting HLS would be fantastic. I saw so many vlogs that where 5 minutes long and 2GB, while I encode full 2 hour movies at half the size.
If Nostr video ever wants to take off this needs to be solved. I've been banging this drum for months.
PREACH BROTHER
HLS would be great! i'd love to see that. users could upload their massive video files and sign them. the video platform could then transcode or stream them. (spoiler: this is essentially what we're doing with diVine.) maybe we need diVine to start the video revolution here?
I wanted to implement it, but (and I am sounding like a broken record here) blossom will blossom will block any uploaded media manipulation.
Nip71 already supports multiple video streams. Good luck getting client devs to build it in a timely fashion though. Coming in 2028 😂
shipyard.pub is very basic when it comes to scheduling. i'd like to see something like hootsuite or buffer. i've used those for social media management for various brand accounts over the years and they work great. we won't get nostr added to them though unless nostr blows up and reaches the masses. someone would need to build something like that. i don't see why this couldn't be added to #notedeck to be honest. it already resembles these apps with various columns.
Shipyard has never worked for me. Hootsuite and Buffer are too basic. They are the worst. HiveTalk is the only post scheduler that works for Nostr.
Have you tried pidgeon.lol for scheduling? I've been checking it out over the last couple days. It's slick. I've never used schedulers so I cant compare, but it's dvm driven & it does quite a lot. What I've used of it seems to work really well.
