NIP-115 Yet Another Geo Tag (ISO-3166-1/2/3)

[dskvr]

trafficstars

This NIP sits somewhere between g defined in NIP-52 and "places" over in #927. It ~extends the g tag~, adds G tag and uses patterns similar to NIP-32. This is the result of patiently watching from the sidelines and conversations from #763. After writing nostr-geotags it was apparent that with NIP-32, a specification for interoperability would still be required. And after all was said and done, would still require domain knowledge of ISO standards to properly use. This NIP provides ~almost*~ full coverage over the well-established ISO-3166 standard (ISO-3166-1/2/3)

~* ISO-3166-1:numeric was removed because it has possible collisions with geohashes~

Primary issues I found with using NIP-32 for geotags:

1. Tag Bloat
2. Lacks self-description
3. Redundancy in both directions, both publishing and filtering.
4. Overly complex and verbose.

This nip is backwards compatible with g tags specified in NIP-52

Implementations:

1. [COMPLETE] Default output of nostr-geotags is in line with this NIP ~I'll add an option to nostr-geotags that produces tags proposed here instead of the NIP-32 tags.~

[vitorpamplona]

hum... some clients may crash on gs that are not geohashes. But after they fix it, this looks ok to me.

You know.. all these L/l and G/g shenanigans could have been solved by a more generic filtering scheme https://github.com/nostr-protocol/nips/issues/267#issuecomment-1457107761. Just saying... :)

[arthurfranca]

G would be needed just if you wanted to request e.g. "All events that have filled g tag with any city name".

It won't really be combined with the g tag as expected, for example { #G: ["countryCode"], #g: ["NA"] } will include both events from Namibia and all events from North America that also have country code filled with any value.

That's why all possible g values must not have ambiguous meanings (NA shouldn't mean a country or a continent).

So we shouldn't for instance represent a country with 4 standards, and instead should pick just one that won't collide with other g entities.

[dskvr]

hum... some clients may crash on gs that are not geohashes. But after they fix it, this looks ok to me.

Sounds like a client-issue, their implementations should be defensive and fault tolerant. Geohashes are always lowercase base32, and all fields in this NIP are specified to have an uppercase letter.

You know.. all these L/l and G/g shenanigans could have been solved by a more generic filtering scheme https://github.com/nostr-protocol/nips/issues/267#issuecomment-1457107761. Just saying... :)

:+1:

It won't really be combined with the g tag as expected, for example { #G: ["countryCode"], #g: ["NA"] } will include both events from Namibia and all events from North America that also have country code filled with any value.

This is not an issue. You post-process the results using gTag[2], which is also required by NIP-32 in some situations.

So we shouldn't for instance represent a country with 4 standards

It's not being represented with 4 standards. ISO-3166 is one standard, that has multiple drafts, and different ways (formats) to express the country. With changes, there will be no more collisions.

Anyways, I removed continentCode [UN M49] and continentName to eliminate standard conflicts.

[fiatjaf]

Looks good.

[dskvr]

nostr-geotags now produces tags in alignment with this nip.

[dskvr]

Removed tag[3] from NIP

• less bloat
• was unneeded, especially since the g namespace is collision free.

[dskvr]

nostr-geotags source and docs updated to support omission of tag[3] from geotags.

[staab]

This seems fine, pretty clean and clear, although my preference would be to make the following changes:

• Use L and l. It doesn't really matter that G labels are related to a particular domain, they're exactly equivalent to regular labels.
• Don't overload g. The current version is very much not a label, and is super useful as such. This avoids having to deal with backwards compatibility.
• Instead of referring to NIP 52 for the definition of g, have NIP 52 refer to this NIP for defining g.

[dskvr]

Use L and l. It doesn't really matter that G labels are related to a particular domain, they're exactly equivalent to regular labels.

@fiatjaf @pablof7z

My primary argument against this is collisions.

Don't overload g. The current version is very much not a label, and is super useful as such. This avoids having to deal with backwards compatibility.

As it is written, NIP-115 would be compatible with all prior NIP-52 notes and clients. ~As suggested, all prior NIP-52 content would be broken.~ As suggested, all clients would have to implement two patterns. I have already implemented backwards compatibility, and it's a single condition. As suggested, it's the maintenance of two separate implementations.

Instead of referring to NIP 52 for the definition of g, have NIP 52 refer to this NIP for defining g.

Makes sense.

[staab]

My primary argument against this is collisions.

The only possible danger is that only for events using multiple L tags, you may fetch some false positives. But that should happen rarely enough that you can just discard invalid results by re-validating client-side using the l tag's second parameter.

As suggested, all clients would have to implement two patterns.

I don't understand this. My suggestion is that you don't change g at all, which would only result in one pattern existing.

[dskvr]

I don't understand this. My suggestion is that you don't change g at all, which would only result in one pattern existing

NIP-32: If I have a client that implements NIP-52, I now have to support both g and optionally NIP-32 NIP-115: If I have a client that implements NIP-52, I simply have to either

1. Add a condition (little more than defensive programming) to ignore NIP-115, all previous and future NIP-52 notes are compatible.
2. Support NIP-115, which is backwards compatible with NIP-52 g tags. All previous previous and future NIP-52 and NIP-115 content works.

...and is super useful as such

As written this NIP is strictly additive, so this statement doesn't actually change. Being nostr, I could (and am) publishing events with g tags that are not geohashes, and so, these clients should be defensive already.

1. Has no affect on geospatial filtering due to collision considerations.
2. Has limited, if any, impact on existing clients (only in the parsing case)
3. Adds new datapoints not possible via lower-resolution geohashes (filtering against legal/political boundaries, language(s) inference, etc)
4. Doesn't inherit third-party labeling, which I cannot identify a benevolent use case in the context of geocoding right now.

I would argue that g was allocated without full consideration over the domain, is a global tag that was added via a very specific use case as opposed to a targeted discussion around the incredibly broad topic of geocoding and so limiting the g tag to only geospatial data whilst relegating ISO-3166 to a generalized pool of values is a disservice to the protocol.

[dskvr]

Primary updates

1. Moved everything to G tag.
2. Added subRegionCode and interRegionCode,
3. Added numeric again since there is no more collision with geohashes.
4. Changed format of regionCode to align with spec.
5. Added ISO-3166-3 alpha-4 representation.
6. Removed cityName due to a lack of standards.
7. Removed regionName
8. Removed countryName

Non-standardized values or values with ISO collisions such as cityName, continentName and m-49:continentCode should use NIP-32.

Need to do

rewrite and rerun collision tests.

requested review from everyone, but tagging @vitorpamplona because has an open review.