nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-25 17:55:51 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

RFC link. Content string/object question resolved

Browse Source
This commit is contained in:
Ross Bates 2023-01-02 16:53:03 -06:00
parent 77e85b41f3
commit f76c78a22d
1 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
44.md
View File

@ -8,7 +8,7 @@ Geospatial Types
## Description
An event of `kind 4326` is a geospatial note supporting various location-based clients such as transportation, travel, home automation, and social media applications. The data for this event is stored in the `content` field and should contain only valid GeoJSON objects.
An event of `kind 4326` is a geospatial note supporting various location-based clients such as transportation, travel, home automation, and social media applications. The data for this event is stored in the `content` field and should contain only valid [GeoJSON](https://www.rfc-editor.org/rfc/rfc7946) objects.
This proposal recommends storing geographic features in standalone events that reference other `e` and `p` tags, similar to how `kind 7` responses work. By requiring geographic features to link to related keys and events, rather than embedding location data within events, collections of notes in nostr will remain composable. Using GeoJSON as the geospatial data type for nostr supports interoperability with existing web standards and designating it type `kind 4326` provides a standard method for future nostr kinds to integrate it in their applications.
@ -139,6 +139,8 @@ To be clear, this decision is not a technical challenge, but as types in nostr b
The most common event on the network is `kind 1` which relays assume will have a string in the `content` field. The `event` object itself is already valid JSON, so allowing for valid JSON to be sent in the `content` would be more efficient for client developers because they would not need to wrap/unwrap and validate JSON content. This could be a complexity trade-off for relays because they would need to support both strings and objects in the content field. Because the `event` must already be valid JSON, and the purpose of the event is that it's entire contents are verifiable by it's signature, it would be reasonable to require relays to support valid JSON in the object field.
*update*: Not wrapping the content would break existing code for things such as event signatures and validation. Continuing to treat all `content` as a string and not an object is the only reasonable path forward right now.
## Other Notes