Maybe NIP-32 using ISO-3166-2, with self reporting:
```
{
"kind": 40,
"tags": [
["L", "ISO-3166-2"],
["l", "IT-MI", "ISO-3166-2"]
],
"content": "{\"name\": \"Milan Cats\", \"about\": \"A test channel.\", \"picture\": \"https://placekitten.com/200/200\"}",
...
}
```
I like this but ultimately a geohash would be best and there is no way to apply a geohash to another event... labels don't really support geohashes. It could work but there is no standard yet.
On the original event, publishing a g tag with the geohash is the right way to do it. Crowdsourcing g tags doesn't exist yet.
Building off daniele's example:
```
{
"kind": 40,
"tags": [
["L", "geohash"],
["l", "9qqj3", "geohash"],
["e", "10fbc672..."]
],
"content": "I'm tagging the location for this event",
...
}
```
This could work? But geo clients need to implement it/expect it.
nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn what do you think? Is this misuse of labels? 🤔 feels like a hack kinda but maybe not
I think this is actually ok, because while geohashes are an ID, it's an ID that applies to potentially many events, so it makes sense to filter by the l value.
Some other nitpicks about this example I just noticed, kind 40's should just use a `g` tag since it's applying the geotag to itself. If that's the convention, then following NIP 32 `["L", "#g"], ["l", "9qqj3", "#g"]` is probably better when tagging other events.
