CloudFlare resizes the image, and encodes it into a different format, depending on the platform it is loaded on.
I'm not arguing against your idea, I'm all for security, I just don't think most image hosts make a bit-perfect guarantee. Mine doesn't. It doesn't store the images in their original format even. Is the hash created after upload? Will this require a special API for hosts?
Here is specific information on CloudFlare.
Amethyst creates the hash after the upload.
So, you can do all the changes you want when uploading, the user will preview the image and if it's good, the app calculates the hash and saves to the Nostr event, thus requiring that your server doesn't change it anymore.
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.
