Ok so I need a storage server integration for our product. Blossom is very simple spec focused on fighting link rot and decentralization, key to which is that uploaded files must not be modified, so my app wouldn't have to trust the server. Blossom invents it's own auth instead of nip98, needlessly.
Wrt nip96, which I didn't consider, but looking at right now, it's much more verbose and covers a lot, and uses hash for addressing, but lacks one critical thing - I want to ask the server to keep the original and do no transformations. Adding this one option would make it a superset of blossom and I would be able to use it. Maybe there's such an option and I missed it in the nip96 spec?
Why do you think that it is a good idea to not transform a media file after it is uploaded? This is infeasible and a little shortsighted. We are not working with medical documents, people want anonymity (modifies file), people want speed (better compression and optimization), people want it fast. If you need a high integrity upload that does not change content, use git and pgp 🐶🐾🫡
You are right 99.99% of the time it's ok to trust the media hosting someone is using for trivial memes etc. But if some controversial video is released, it would be great if anyone could re-upload the original to other servers and they'd all serve the original and any client could verify it's original, etc. That's the problem blossom is solving.
Re. my use case, I'd like to host some code in the same "link rot avoiding way", and I know you wouldn't probably transform it anyway, but I will also upload images that shouldn't also be transformed. I haven't considered git, and maybe I could even just host it all in nostr events... We'll see.
My point in posting here was to understand what problem blossom solves vs nip96, and I'd say a small addition to nip96 could make it supercede blossom and you could then just ignore it :)
The biggest beef I have with this is that people demand integrity from media host, and then that go ahead and use imgproxy or any other alternative to perform their tweaks and present it to the user. How the fuck is it still the same thing when it is wasting hosts bandwidth and yet achieving nothing in terms of integrity? As for the video, uploaded can confirm that the content is the same after the fact and accept optimized and transcoded version and have a hash for it, and problem solved 🐶🐾🫡
I agree with you about imgproxy, but then there's no NIP for "accepting optimized version after the fact" and I'd say it's probably much trickier than you say. Anyways, you don't have to offer this option if you don't like it, I'm just comparing the NIPs.
If there is a good use case and it is really needed, it can be offered for sure. The problem I have is that I am wasting a ton of time on implementing something just to start over to implement some other hype. This is just wasting time and effort, instead of trying to innovate and find a better approach. Content hashes do exist, and if that is needed, it can be done 🐶🐾🫡
100% agree, that's why I'm saying offering this as nip96 option (even if paid, restricted etc) could serve those use cases, and I'm guilty as anyone in digging hyped stuff without looking through existing NIPs first. And you sure didn't waste time implementing nip96, it seems to be quite good, even if a bit too verbose for my taste.
There is a PR now to simplify it. Please submit a PR that will request immutability of the media. Also allow for the host to reject the upload based on presence of private metadata and viruses/exploits. Once you have it in, I will make sure to comment and implement once it’s merged 🐶🐾🫡
People saving and reuploading video. With Even small amount of quality loss your og 8k video is soon 480p. Without compression video quality stays same despite any numbers of downlods and reuploads.
That’s not how things work on the internet, unless all your knowledge came from YouTube 🐶🐾🫡
There is no way to specify that the server (from a client), but you can know if a server will transform or not through its nip96.json file.
In this way, you can choose which server to use, the one that best suits your preferences.
Thinking about it, it would not be difficult to implement. But then the server could deny it to you depending on whether you have access to that service or not.
Ok I will check existing servers to find one that doesn't transform. Consider adding that as an option per upload.
I initially tried to use NIP-98 auth for the blossom spec but its requirement for the "u" tag and the full domain + path of the endpoint made it only useful for uploading to a single server
For blossom I needed a single auth event that would allow users to upload a blob to multiple servers. or for the server to upload it to other servers if that was a feature the server offered
Oddbean new post about login | logout