Well, respectfully, that will end my being able to host images for Nostr. It will also rule out several very large backends from being usable, and rule out a lot of potential bandwidth optimization.
I very much respect your goal here, but as stated, it will not be feasible for me to contribute space to Nostr images if this becomes a requirement.
Will this be an optional feature?
I am sure some clients won't verify the hash. Amethyst will still display the image for now but with a red warning on top of it.
Do you mind explaining why do you must change the image afterwards? I don't think users expect that at all.
The software I am using (FOSS) provides functionality that allows the user to link to their uploads in a multitude of formats. In the backend, it stores all images as QOI format for efficiency reasons. Upon request at a generated URL, whatever format they request is generated and cached for a time period.
This is a minor thing. Other image hosts resize images for smaller screens to save bandwidth. Data usage is already a top complaint I hear from fellow nostriches, so I think these things should be considered inv your planning. Images are heavy, and we should eventually be able to optimize for that.
Again, I love the idea of tamper evidence, but wondering how this can work. Is there a way to use perceptual hashing?
Is it theoretically possible to have a hash function compatible with a resizing algo? For instance, if the resizer agreed to keep every N pixels intact, and the hash function only hashes those particular pixels? Likely N would have to be large enough to make it difficult to create a fake replacement image. Maybe every fourth pixel, which would be compatible with image resizing to 50% or 25% directly. Or every pixel in the center square of the image?
But really, I still don't understand the problem with #[7] method.
Don't mind me, I'm drinking.
