If you are a #nostrdev and can help with why the audio on this master file is having problems let us know 🧡 @nostr.build distribution should work and has worked before. #nostrmusic #musicvideo 💜
View quoted note →
Login to reply
Replies (66)
i think the problem is that nostr.build can't stream this fast enough. it took me a long while to download it, but once i did, it played just fine for me. @The Fishcake (nostr.build) this looks like a 1.6GB file. is the size the issue? you're not doing any transcoding so that could be it?
Oh. That’s a huge file size for a short video.
yes. it's not going to be a good time for anyone.
Thanks @Derek Ross - but @nostr.build is a paid service for $71 a year and that needs to be resolved. 🤦♀️ #grownostr #nostrdev #userfeedback
I was just going to comment this. It's a huge 4k file. Here's a web friendly version, signing in at about 33MB 👍
Look into using Handbrake to compress your files for Nostr uploads.
If you have any questions I'd be available to help.
HandBrake: Open Source Video Transcoder
HandBrake is an open-source, GPL-licensed, multiplatform, multithreaded video transcoder.
hah. awesome. my transcode is almost done at 88%. ill stop it since you already did it :) thank you sir!
This should be an @nostr.build issue. If there will be a problem seeing it in Nostr - @nostr.build should help the user resolve it before it gets posted.
I may have some experience shrinking movies 😂
sure, i understand that. that said, most applications allow you to export for the web or export for youtube, etcl., whenever you export a video file. you'll get an option to choose the quality and the format. if you choose a web or youtube quality format when you export, you'll have better luck here since nostr.build doesn't do video transcoding. they do image compression though so maybe it's something that they could offer. you'd have to ask them :)
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.
Unlike centralized social media your videos aren't automatically optimized on Nostr. Here are some good tools to compress your videos for smaller size and better streaming before upload.
"Make sure to make it web optimized and no more than 720p. Or even 480p is great for a long news like segments 🐶🐾🫂🫡💜"
- @The Fishcake (nostr.build)
🔹Android
Light Compressor enhanced
by @⚡ Dee Kay ⚡🇸🇪🇬🇧🇨🇿🇧🇷🇦🇹
https://github.com/davotoula/LightCompressor-enhanced
Proton - Google Play Store
https://play.google.com/store/apps/details?id=com.arthur.hritik.proton.video.compressor
🔹iOS
@nostr.build Shack
by @The Fishcake (nostr.build)
https://testflight.apple.com/join/qgkAMPgU
🔹Desktop - available for Linux, Mac & Windows
Handbrake
Handbrake looks complicated, but there are presets available. Under General, Fast 720p30 & Fast 480p30 will be good options. I would also enable the Web Optimized option for better streaming.
FFmpeg
https://ffmpeg.org/
If you are comfortable with the terminal FFmpeg is a best in class option. LLM's are useful to formulate your commands.
View quoted note →
HandBrake: Open Source Video Transcoder
HandBrake is an open-source, GPL-licensed, multiplatform, multithreaded video transcoder.
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.
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.
What is the issue? Big files will inherently have issues, we do not transcode. There is absolutely no need for a five minutes video to be anywhere close to 1.6GiB. HD movies (fully featured movies) can fit in that size at top notch quality. 4K 5M video should be very much under 400MiB.
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 🤷♀️
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.
This is the HD video master file that I would distribute to distrokid or any distributed for my music or videos - for less than $20 a year. Same file I distributed that will come out on traditional distribution on 1/5
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.
PREACH BROTHER
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.
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.
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?
Well, say thanks to blossom to make it nonnegotiable to alter any uploads
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.
Must be really cold where you are 😉
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.
It’s too big for sharing. I even created 
to help users overcome limitations imposed by the nostr protocols geared for media uploads
App Store
Nostr Build Shack App - App Store
Download Nostr Build Shack by Big Nut Media LLC on the App Store. See screenshots, ratings and reviews, user tips, and more games like Nostr Build ...
To that end nostr.build already can support HLS. Amethyst as well supports HLS. Where are the other devs building support into their clients?
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
oh i just used shipyard recently because someone asked me about it and i wanted to make sure it still worked before i recommended it. what doesn't work for you?
I could even produce HLS if ya’ll stop screaming “but sha256 doesn’t match”
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.
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
Cold pool I guess 😂
i haven't heard of it. thanks dawn! ill check it out.
No, but I will! I have another one in a tab waiting to be tried…
Never has.
You should. You can pick which relay or relays, media servers, and dvms it uses. It has a schedule calender, dms, repost scheduling, drafts... it's wild.
Nostr on so many fronts 🤦♂️
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.
This. 💯 is my issue as a creator with #nostr
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.
Yes, 1.6GB is too large for social media streaming. We don’t compress or do anything to the video..
We are looking at video transcoding/compression options, but it takes a lot of work and compute. We did just launch Nostr Build Shack which compresses video, but is a separate process.
App Store
Nostr Build Shack App - App Store
Download Nostr Build Shack by Big Nut Media LLC on the App Store. See screenshots, ratings and reviews, user tips, and more games like Nostr Build ...
and if you did then people would still be upset that's its lower quality.
I’ve never thought about this before.
But thank you for committing to this. 🫡
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.
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.
Need media clients to hash and sign 10+ different resolutions from master down to 144 - let them get distributed everywhere so that fakes can't compete and creators can be zapped into perpetuity.
By now everyone knows everyone here. How difficult could it be to address a user problem and ask others to support a solution?
At least make the implementation before the nip. This is why I don't believe in nips.
there's quite the graveyard here of those such things
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.