provoost on Nostr: I agree exif info should be stripped from photos by default. They were in my ...
I agree exif info should be stripped from photos by default. They were in my Instagram archive, so my Instablossom script uses them both directly and to generate the geohash.
When posting a note (with or without a photo) a client should ask if the user wants to share their location, e.g. npub142gywvjkq0dv6nupggyn2euhx4nduwc7yz5f24ah9rpmunr2s39se3xrj0 (npub142g…xrj0) does this.
It can then obtain the location from either the device GPS or from the photo exif data (before removing it). The photo may have been taken in the past so these are not always the same location.
But then the question is how to share the location. If the user is ok with an exact location, e.g. because it's a tourist snapshot so it's not sensitive, then wgs84 exact coordinates seem like the right default.
If the user wants to be more careful, they may want to use an inaccurate geohash. Amethyst picks roughly a city size resolution (5km) which is a good default. In that case wgs84 should not be used, because there's no good convention on how to round decimal coordinates. This would lead to confusion when trying to plot images on a map.
Back in the day Instagram even had three modus for the user: no location, rough location and accurate location.
When location is set to high accuracy, it makes sense to use both standards: wgs84 for general purpose mapping tools, and a geohash at multiple zoom levels for easier search on relays.
You could also recommend a single geohash, at the highest resolution a user is comfortable with. However that would require relays to implement the spec as well. Either by supporting startsWith() string matching or by using something like ST_GeoHash in Postgres. Especially the latter seems like a rather heavy requirement. The redundant tags don't use that much space.
I do plan to open a PR once I'm a bit more familiar with earlier work and gathered some feedback.
Should this be a new NIP or expand nip-52?
When posting a note (with or without a photo) a client should ask if the user wants to share their location, e.g. npub142gywvjkq0dv6nupggyn2euhx4nduwc7yz5f24ah9rpmunr2s39se3xrj0 (npub142g…xrj0) does this.
It can then obtain the location from either the device GPS or from the photo exif data (before removing it). The photo may have been taken in the past so these are not always the same location.
But then the question is how to share the location. If the user is ok with an exact location, e.g. because it's a tourist snapshot so it's not sensitive, then wgs84 exact coordinates seem like the right default.
If the user wants to be more careful, they may want to use an inaccurate geohash. Amethyst picks roughly a city size resolution (5km) which is a good default. In that case wgs84 should not be used, because there's no good convention on how to round decimal coordinates. This would lead to confusion when trying to plot images on a map.
Back in the day Instagram even had three modus for the user: no location, rough location and accurate location.
When location is set to high accuracy, it makes sense to use both standards: wgs84 for general purpose mapping tools, and a geohash at multiple zoom levels for easier search on relays.
You could also recommend a single geohash, at the highest resolution a user is comfortable with. However that would require relays to implement the spec as well. Either by supporting startsWith() string matching or by using something like ST_GeoHash in Postgres. Especially the latter seems like a rather heavy requirement. The redundant tags don't use that much space.
I do plan to open a PR once I'm a bit more familiar with earlier work and gathered some feedback.
Should this be a new NIP or expand nip-52?