nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-27 02:35:52 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

typos and clean up

Browse Source
This commit is contained in:
Ross Bates 2022-12-30 07:51:46 -06:00
parent d3ffa27d73
commit 6abc7ec18f
1 changed files with 10 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
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 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 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.
@ -36,7 +36,7 @@ The meetup is taking place at the Bitcoin Commons in downtown Austin represented
```
At 5:30 User A posts a kind 1 note using their nostr app reminding everyone about the event. In this note they tagged both the location as well as the 2 friends who will also be attending. This was done using the `e` tag for the location and the `p` of the contacts.
At 5:30pm User A posts a kind 1 note using their nostr app reminding everyone about the event. In this note they tagged both the location as well as the 2 friends who will also be attending. This was done using the `e` tag for the location and the `p` of the contacts.
```json
@ -55,8 +55,7 @@ At 5:30 User A posts a kind 1 note using their nostr app reminding everyone abou
}]
```
In the same post User A chooses the option to attach their current location (created as `kind 4326`) to the post. The app generates an event referencing the original `kind 1` note which goes to all public relays, while and both events gets posted to a private relay. At this point the client is still able to filter for all public and private responses to the `kinda 1` note.
In the same post User A chooses the option to attach their current location (created as `kind 4326`) to the note. The app generates an event referencing the original `kind 1` note which goes to all public relays, while both events also get posted to a private relay.
```json
["EVENT", {
@ -72,9 +71,9 @@ In the same post User A chooses the option to attach their current location (cre
}]
```
Users A,B and C all have access to the same private relay which supports receiving and responding to `kind 4326` messages. When user A sends the location update that includes `p` tags it automatically generates a `kind 1` note for all parties.
Users A, B and C all share access to the same private relay which supports receiving and responding to `kind 4326` messages. Also at this point each client is able to filter for all public and private responses to the `kinda 1` note. When user A sends a `kind 4326` note that references `p` tags it can automatically generate a `kind 1` note for all parties. This is just an example, the client developers can customize the experience however it best suits the users.
User B & C are able to respond using only a `kind 4326` note over the same private relay. These responses can include their current location coordinates, as well as other any other related `p` tags such as the Coffee Shop or Park they're currently at.
In this example user B & C are able to acknowldge and respond using only a `kind 4326` note sent over the same private relay. These responses can include their current location coordinates, as well as other any other related `p` tags such as the Coffee Shop or Park they're currently at. The location data is the response.
User B Response:
@ -108,10 +107,10 @@ User C Response:
}]
```
This is a basic example to demonstrate the data structures showing how the initial handshake between peers would work. From here the private relay now has everything it needs act as a coordinator executing geofence and nearby queries on the notes, generating arrival estimates, routing suggestions, ride-share integration. There are many options that go beyond the scope of the NIP.
This is a basic example to demonstrate the `kind 4326` data structures and for showing how an initial handshake between peers over public and private relays would work. From this point forward the private relay now everything it needs act as a coordinator - potentially executing geofence and nearby queries on the notes, generating arrival estimates, routing suggestions, ride-share integration, etc.... There are many possibilties for client experiences that go beyond the scope of the NIP.
## Other Considerations
## Summary of Benefits
**Privacy Controls**: notes with `kind 4326` can be routed separately to private and/or user specified relays for handling. This provides users with options to protect their private data if they choose, and it provides client developers a solution for combining public and private data into composite events. Beyond the protocol, we hope this design will prevent the abuses of the current generation of mobile apps which aggregate location data and monetize it on 3rd party ad-networks without the knowledge of their users.
@ -126,13 +125,13 @@ This is a basic example to demonstrate the data structures showing how the initi
### NIP-16
What is the desired behavior when it's reasonable for an event to be either a Regular event (`1000 <= n < 10000`), Replaceable event (`10000 <= n < 20000`), or Ephemeral (`20000 <= n < 30000`) event as defined by NIP-16? Take for example a bus tracking application where the users are checking on the status of their bus identified by:
What is the desired behavior when it's reasonable for an event to be either a Regular event (`1000 <= n < 10000`), Replaceable event (`10000 <= n < 20000`), or Ephemeral (`20000 <= n < 30000`) event as defined by NIP-16? Take for example a bus tracking application where the users are checking on the status of their bus identified by.
```json
["p", "b68cf380888a13fab39afb144fb9e9502a8560af85943fa0cdcf1e3e130a109d"]
```
A solution could be a new type created such as `kind 14326` or `kind 24326` for use as the "current status" location. If however the client app is also tracking the history of the bus then `kind 14326` is equal to the most recent `kind 4326`. Should this be something defined by the protocol, or left up to the developers?
As the bus travels it's route it will generate a series of location updates. One solution could be a new type created such as `kind 14326` or `kind 24326` for use as the "current status" location. If however the client app is also tracking the history of the bus then `kind 14326` is basically equal to the most recent `kind 4326`. Should this be something defined by the protocol, or left up to the developers?
To be clear, this decision is not a technical challenge, but as types in nostr begin to increase some guidelines for how these types are assigned and used will need to be figured out. For now this NIP proposes using only `kind 4326`