Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NIP-G0 for Geospatial Tagging Standardization #1642

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
142 changes: 142 additions & 0 deletions G0.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,142 @@
NIP-G0
======

Geospatial Tags for Nostr Events
--------------------------------

`draft` `optional`

This NIP offers a standard for geospatial tagging in Nostr events. It defines a flexible structure to designate an event's location and area of impact or relevance. By implementing this standard DVMs, clients, and relays can enable location-based search, filtering, and user discovery through location based notes.


## Goal

Geospatial data is helpful for many use cases, such as:
- Localized news or alerts to be tagged by outlets to target audience and strengthen search.
- Bot and DVM content filtration handles to allow user custom feed tweaking.
- Events with regional or global impact can be filtered according to interests.
- Community engagement based on proximity and better connections allowed for users to find users of interest.
- Privacy-conscious clients can allow tagging by creators to share relevance of content and controled-precision while sharing any of the creator's own location.

This proposal defines a lightweight and hierarchical tagging approach, while ensuring backward compatibility.


## Specification

This NIP defines two primary tag types: **`geo_loc`** and **`geo_rel`** and one additional convenient compatibility tag **`w3w`**.

### 1. `geo_loc` [optional, repeatable] The geo-location of the event.
Represents the event’s origin location. Each tag specifies a geographic or political level. Multiple tags may be used to define a hierarchy. This structure may be quite flexible in eventual usage, but by predefining a base set, client usage benefits from establishing early consistency:
- `"location"`: (optional) Precise point as GPS long,lat coordinates.
- `"w3w"`: (optional) Precise point on earth using [what3words](https://en.wikipedia.org/wiki/What3words).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Closed source system. And we already have GPS coordinates, why have this?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optional usage within the NIP standardization. Not pushing it, just allowing it with the flexibility of the NIP-G0 standard. Some useful systems utilize w3w and this would accommodate that usage without impact to gps usage. Could even use in tandem to gps for compatibility.

- `"g"`: (optional) Precise point as a [geohash](https://en.wikipedia.org/wiki/Geohash) as in [NIP-52](52.md).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Multiple ways of doing the same thing? Why?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optional and varied approaches depending on the systems posting and the systems consuming. Useful flexibility within the structured geographical association of content by the NIP-G0.

Copy link
Author

@swbratcher swbratcher Jan 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additional thought: The other way is to not allow for multiple systems to be compatible and restrict to GPS. Redundancy allowance seems more resiliant to allow for lack of government-controlled GPS access, or desire for only open source by a user, or proprietary system use for those users who find that more useful. Limiting to GPS may still allow w3w conversion by the w3w api and geohash generation on the client side, but open acceptance of any currently prominent method of location identification by the NIP-G0 standardization would potentially future-proof functionality in a freedom-tech environment.

- `"dist"`: (optional,repeatable) Ward, Neighborhood or sub-municipal area.
- `"muni"`: (optional,repeatable) Specified municipality, city, town, etc.
- `"metro"`: (optional,repeatable) Metropolitan area that is multi-municipal in context.
- `"county"`: (optional,repeatable) County or similar administrative division of a state or province.
- `"reg"`: (optional,repeatable) Region named or general, non-state, non-province.
- `"canton"`: (optional,repeatable) Canton or similar administrative division of a nation.
- `"state"`: (optional,repeatable) State specified.
- `"prov"`: (optional,repeatable) Province specified.
- `"nat"`: (optional,repeatable) National context.
- `"cont"`: (optional,repeatable) Continental context.
Comment on lines +33 to +42
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where's the standard for these naming schemes?

Copy link
Author

@swbratcher swbratcher Jan 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


Example: Location with heirarchy.
```json
["geo_loc", "muni", "Jefferson City"]
["geo_loc", "reg", "Missouri"]
["geo_loc", "nat", "USA"]
```

Example: Precise location.
```json
["geo_loc", "w3w", "farm.vines.index"]
["geo_loc", "g", "9yy7vdxxy2g6s6qf"]
```

### 2. `geo_rel` [optional, repeatable] Event relevance or impact.
Represents the geographic or political areas affected or relevant to the event. The parameter structure mirrors `geo_loc` and can also include multiple locations to define broader or specific impacts.

Examples:
```json
["geo_rel", "muni", "Kansas City"]
["geo_rel", "muni", "St. Louis"]
["geo_rel", "state", "Missouri"]
["geo_rel", "nat", "USA"]
```

No `geo_rel` tag present could indicate a global relevance or this tag could remove ambiguity:
```json
["geo_rel", "global"]
```

### 3. `w3w` [optional, repeatable] Precise location(s).
Represents the geographic or political areas affected or relevant to the event. The parameter structure mirrors `geo_loc` and can also include multiple locations to define broader or specific impacts.

Examples:
```json
["w3w", "///farm.vines.index"] # The triple-slash w3w standard syntax.
["w3w", "farm", "vines", "index"] # The 3 words as three values.
["w3w", "farm.vines.index"] # The 3 words dot-separated
swbratcher marked this conversation as resolved.
Show resolved Hide resolved
```


### Added Standardized Tags (to update list in [README](README.md))

| name | value | other parameters | NIP |
| ----------------- | ------------------------------------ | ------------------------------- | -------------------------------------------------- |
| `geo_loc` | The geo-location of the event. | `location`, `g`, `w3w`, `dist`, `muni`, `metro`, `county`, `reg`, `canton`, `state`, `prov`, `nat`, `cont` | [NIP-G0](G0.md) |
| `geo_rel` | The event impact or relevance. | `location`, `g`, `w3w`, `dist`, `muni`, `metro`, `county`, `reg`, `canton`, `state`, `prov`, `nat`, `cont` | [NIP-G0](G0.md) |
| `w3w` | A what3words precise location. | See examples for parameters. | [NIP-G0](G0.md) |


### Usage Notes
- Both `geo_loc` and `geo_rel` are optional.
- Tags are designed to be lightweight and compatible with existing Nostr infrastructure.
- Clients and relays that do not recognize these tags will ignore them without disruption.


## Rationale

This design leverages Nostr’s existing flat tagging structure to ensure compatibility and ease of use:
- **Flexibility**: Supports diverse use cases, from hyperlocal events to global phenomena.
- **Privacy**: Allows generalized or anonymized location tagging.
- **Compatibility**: Relies on standard tag processing, ensuring backward compatibility.


## Security Considerations

Geospatial data may raise privacy concerns. Event creators should carefully select the level of detail in location and impact tags to balance utility with privacy. Client-side tools should allow users to obfuscate or anonymize location data where appropriate and have visibility to the tags being set to notes by default or per note selections.


## Backward Compatibility

This NIP does not affect existing Nostr functionality. Tags introduced here are optional and will be ignored by clients or relays that do not implement this NIP.


## Example Use Case

**Missouri State Law Example:**
```json
{
"id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"pubkey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"created_at": 1702137600,
"kind": 1,
"tags": [
["geo_loc", "muni", "Jefferson City"],
["geo_loc", "state", "Missouri"],
["geo_loc", "nat", "USA"],
["geo_rel", "muni", "Kansas City"],
["geo_rel", "muni", "St. Louis"],
["geo_rel", "state", "Missouri"]
],
"content": "Missouri has passed a new state law that directly impacts municipal regulations in Kansas City and St. Louis. The law, focused on zoning changes for housing developments, applies only to these cities while exempting others in the state."
}
```

## Reference

- [NIP-01](01.md): Basic Event Structure
- [NIP-52](52.md): Event Categorization and Metadata offers `g` and `location` tags.
- [Geo heirarchies](https://wikitravel.org/en/Wikitravel:Geographical_hierarchy)