Its getting stripped on device somewhere, i just checked another image on olas.app and it has the GPS data, maybe its only a problem for the iOS Olas app?
Discussion
Maybe that's it?
It’s either app/os does the stripping or blossom server mods the file and breaks checksum.
Here is Corn uploading my image via iOS Olas.
And here is me uploading it via Android Olas.
Both using the same image to nostr.download Blossom. His version has GPS. Mine does not.
The point is that blossom, using standard /upload API, does not allow for any manipulation of the media at all. If image is huge and has bunch of exif data in it, it will remain as uploaded. If client has a bug, or Android/iOS changes an api or something, the image will be exposed to potential leakage of metadata. Server could check and refuse, but I know that only nostr.build has it now for no_transform uploads using API (or account page). Some other servers may have it implemented too, but I don’t know of any.
so.. wen client with auto-stripping option before image upload?
IMHO client is the first line of defense, server should act as a failsafe and either refuse upload or have an option to strip. You can’t trust one entity to keep your privacy.
you're right. but I think it would help if clients had such an option instead of (maybe) having to use a 3rd party app which does (or maybe doesn't) strip all the data. then have the server do a check and return a warning if metadata is found. at that point the user can decide if he cares or doesn't. Or strip the data server side but from what I understand that breaks the checksum?
Warnings don’t work, normal folks learned to ignore them due to warning fatigue. Refuse to accept is the only way. Stripping with default blossom will not work, csum will break, and honestly I don’t think any of the clients even check. SHA256 is slow and not the best for that, Blake3 is much faster and as reliable.
oshash is fast
SHA256 by itself is great for cryptography, Blake3 is just very fast on modern CPUs and outdoes SHA256 by miles. Regardless of implementation
It’s a great and super-fast algorithm, especially the WASM implementation! But until it’s bundled by default in Linux, other major OSes, and browsers, it’s unlikely to go mainstream. Switching algorithms is pretty tricky once you’ve committed to one. Still, Blake3 is definitely impressive!
Agree. I am still planning to use blake3 to produce hash and keeping it as an alternative.
Sounds great! I’ve always been a fan of Oshash for media—it integrates so well with the OpenSubtitles ecosystem, which has most of the world’s content indexed. I remember it was quite a challenge and even a bit controversial when they switched to a better hashing algorithm. I think the resistance came from the sheer scale of the ecosystem and the compatibility issues involved, but it’s impressive how they made it work in the end!
It seems that it does not read the full file to produce hash, which can be OK for some use cases but not ideal for integrity. 🤔
uff truth on the warnings!
Maybe, but either way there should be NO metadata, also the images are huge and not compressed at all