It's very close, but NIP 96 priotitizes server-side transforms over referential transparency. If I am understanding it correctly, if you download a file by hash, you are not guaranteed to get the original file. That means you can't freely and confidently replicate files the way you can replicate nostr events, because the hash can't always be verified.
That indeed felt overly negative. Nip96 is built by people who understand media hosting, and that has to be reconciled with our desire for verifiable replication etc. Media hosting is 99% of current file uploads, feels pretty important.
Why not decouple the two? Send the file to get processed, plus a callback url to referentially transparent hosting?
Is there a proposal/thread on GH with more details?
No, but coracle does strip metadata and compress images prior to uploading. There's no reason you couldn't extend that behavior to involve another server. Seems like a good idea to me, but I'm not working on file hosting to avoid getting spread too thin.
Ideally images and videos are transcoded to optimal format and then several copies are created with different resolution etc. And that could be done on client or server. And if on server then there is trust involved. And then appropriate version of file has to be served depending on client needs. And then it should be content-addressable, with as little trust to third parties as possible. That's just what comes to mind, and it's already much wider scope than what blossom covers. I am not saying nip96 covers it all, but it's authors are trying to reconcile all this. Seems like a good effort to me.
I don't think the modified ones need to be content-addressable, just the originals. Imgproxy does this on-demand for images, so I don't see why you couldn't just use that or a service like that as a front-end for blossom. This would allow you to trade-off referential transparency for performance depending on reader use case. Of course, there are also many files that publishers don't care about censorship resistance and verifiability for, but in that case I would just use a traditional image host.
And if you want referential transparency for a transcoded one, then transcode it and then upload it to blossom
Its great that there are clients that compress media before uploading. But one of the good things of NIP-96 is that it makes it easy for clients to offer uploads by not requiring any client-side media transformation logic.
If we wanted things to be easy, we wouldn't be building on nostr
An amend to NIP-96 could add a query string like `?ref=x` when downloading to only respond succesfully if server has a file with `x` value equal to the hash used to request the file.
For uploads, NIP-96 already has "no_transform" field, which would make `ox` equal to `x`.
Yes, that would be a step closer. But that feels like a lot of band-aids to get what blossom has out of the box, and by design. no_transform would also still only be opt-in, and the spec says servers can reject those requests. NIP 96 gives servers too much latitude to have a strong guarantee of referential transparency.
Oddbean new post about login | logout