NIP96 clearly defines (and by the way, with the consensus of many people) the basics for any media server, what is the point of differentiation with blossom? I am seriously asking 😅😀 nostr:note1n22fhh0vyj35ajm4vn6c64uyzkejwfdf3vfhvl9f4pgv9l7d828sg0aupt
Discussion
There will be nothing but silence. People love hypy names! 🐶🐾🤣
Nips are sexy enough for me 🤣🤣🤣
As someone who runs a NIP 96 server myself, I would be curious to know the difference between this and Blossom.
I've been assuming it's just the brand name for that particular implementation.
That's what I thought, I have asked seriously because I am not able to find differences
NIP-96 is slow and not efficient, storing images as JSON blobs. There's also clearly a size limit too, before it just doesn't work and uploads fail. Clearly we need something better.
I think you are confusing the old proposal by Vitor, not the current NIP96 🐶🐾🫡
Oh Vitor's NIP-96 was finally denied or closed?
Oh that's NIP-95. My bad. NIP-95 is what I am confused with.
This! I did not remember the number
We have too many NIPs now 😂 Back in my day, I knew them all by heart!
The OG’s only used one NIP, this is getting out of hand 🤣🤣
Have you been following NIP-01 proposals. 👀 Gonna end up needing a bunch of NIPs just to write one event. 😂
Which servers support nip96? nostr.build?
At least these:
https://github.com/quentintaranpino/NIP96-compatible-servers
There must be many more, using any of the servers available to install on premise (nostr.build void.cat and nostrcheck). But many are private and do not want to be on this list. Hosting files publicly is really intense and dangerous 🥲
Yeah I found that link, thanks!
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 🐶🐾🫡
Deal, thank you!
https://github.com/nostr-protocol/nips/pull/1236
Is the PR I talked about 🐶🐾🫂🫡
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
The core difference between blossom and NIP-96 is the focus on re-uploading files
If we want censorship resistant media then we need to be able to re-uploaded the files to other servers. similar to now nostr events get spread around the network
NIP-96 could support re-uploading files but it isn't currently part of the nip
There is also the difference that NIP-96 has a "/.well-known/nostr/nip96.json" file and customizable endpoints. In my view this is not a feature and makes it much more difficult to work with servers since clients must first fetch a map of the endpoints before they can talk to the server.
Blossom however requires blobs be served from the root of the domain ( example.com/
Also searching for a missing blob is a simple as replacing the domain. something a user could easily do ( and understand ) in the browser address bar
There are more smaller differences but in my view these are the major ones
server admins who can't make subdomains or rewrites are not very competent
but why does blossom not allow a path prefix?
That‘s the kind of complexity-tear-down I like 👌
Hey, can you give me a Blossom link that I can add to my Nostr spec registry?
Then we could list it right after the NIP-96 entry.
I was thinking of adding topic labels or something, anyway, but it would already help if we sort a bit by topic.
The blossom spec lives here https://github.com/hzrd149/blossom
Also added a few wiki pages for it. but I need to add a lot more info
nostr:naddr1qvzqqqrcvgpzqfngzhsvjggdlgeycm96x4emzjlwf8dyyzdfg4hefp89zpkdgz99qqrkymr0wdek7mgy65kuf
nostr:naddr1qvzqqqrcvgpzqfngzhsvjggdlgeycm96x4emzjlwf8dyyzdfg4hefp89zpkdgz99qq9xk6twvsarzvpsxcestdhm6h
Why does the path need a “.ext”? The sha256 should be enough, right? Why confuse things with whether it’s a jpg, pdf, gif, etc as part of the path?
Servers should serve the blob with and without the .ext
The .ext is just optional because its useful for clients and users to get an idea what type the blob is without downloading it first. a lot of web apps look for `.png` or `.jpg` on URLs before they show them as images
Is there some kind of metadata about the blob in blossom? If not, is it even possible as an extension on the protocol?
It is very useful for clients to understand the data before downloading the actual data. One good example would be image resolution so apps can prepare the layout properly before image is loaded. This helps with performance and cleaner ux.
Servers can offer additional metadata on media or any other file type but none of the metadata is synced or stored on other servers.
You could store some metadata in k:1063 events or NIP-94 tags though
It would be awesome if Blossom would provide that info in the response header. That way apps could make an http request for just the header without downloading the whole thing.
Hello, sorry I couldn't respond to you yesterday. First of all, thank you for answering my questions!
Re-uploads are fully supported in NIP-96. In fact, I implemented this in Coracle also relying on NIP-94. It was ultimately discarded, but it is 100% possible.
As for serving blobs at the root, I don't see the point. It is true that it is easier for a human to read, but this shouldn't force someone to reimplement a standard. I see it as pointless.
In any case, I will study Blossom in depth. I'm sure there is much to learn from it, but I think your efforts would be much better focused on helping with NIP-96 instead of reinventing the wheel.
This is my humble opinion, and I hope to open a good debate with this.
Nice to meet you, by the way!
I figured re-uploading could be added to NIP-96 but that's not its focus. If someone were to create another server that implements NIP-96 chances are it wouldn't have the ability to re-upload. since its not a requirement in the nip.
Blossom on the other hand requires servers to support re-uploading (uploads without modifications) and media optimization can be an optional endpoint
The requirement for re-uploading blobs is critical if we want media to be censorship resistent-ish and available on multiple servers. This is also why it has the requirement for serving the blob at the root path. this allows users and clients to easily ask an unknown server for a blob without having to get a "map" of the endpoints
I decided not to put my efforts towards NIP-96 because I think its more complicated than it needs to be and it only focuses on uploading. where as my focus with blossom is on downloading and distribution
Thanks for your interest and I'm happy to answer any questions you might have
Look at the PR I proposed for nip96 some time ago. It was not accepted but I think it is in line with what you are looking for with blossom.
Whats the purpose of adding the pubkey to the URL when in most cases its available from the kind 1 note the URL was posted in?
Also its possible for multiple pubkeys to upload the same file, although this could easily be fixed by making each pubkey work in the URL
However the biggest missing piece here is the ability to re-upload your (or someone else's) files without modification. censorship resistance isn't going to work if you have to ask the original server first before you migrate