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

remove opinions not related to protocol

Browse Source
This commit is contained in:
Ross Bates 2023-01-01 08:49:46 -06:00
parent ab21106187
commit 77e85b41f3
1 changed files with 7 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
44.md
View File

@ -21,7 +21,7 @@ An object represented by `p` could potentially be a fixed location such as a bui
Here is an example of how the use of `kind 4326` notes could be used in a real world example. In this scenario there are 3 nostr users (A,B,C) attending a nostr developer meetup in the evening who would like to privately share their location with their trusted contacts so they can coordinate dinner and transportation. They'll do this using the same nostr mobile app they use to communicate with a wider group of people. Here is an example of how the use of `kind 4326` notes could be used in a real world example. In this scenario there are 3 nostr users (A,B,C) attending a nostr developer meetup in the evening who would like to privately share their location with their trusted contacts so they can coordinate dinner and transportation. They'll do this using the same nostr mobile app they use to communicate with a wider group of people.
The meetup is taking place at the Bitcoin Commons in downtown Austin represented by the following note. The meetup is taking place at a building in downtown Austin represented by the following note.
```json ```json
["EVENT", { ["EVENT", {
@ -113,7 +113,7 @@ This is a basic example to demonstrate the `kind 4326` data structures and for s
## Summary of Benefits ## 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. **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.
**Proof of Location**: This design makes it so anyone is free to build validation and attestation services that an event took place in a physical location. For example, users could check-in at a concert using any nostr client to receive a special badge. Attestation and issuance could originate from any number of trusted sources, such as the artist and/and venue, without requiring users to be running a specific application or platform. Attestation could come from sources such as nostr peers, payment systems, photos or QR codes - or a combination of these using nostr multi-sig. Location proofs could be provided for any valid event, by any signer, with no barriers to entry. **Proof of Location**: This design makes it so anyone is free to build validation and attestation services that an event took place in a physical location. For example, users could check-in at a concert using any nostr client to receive a special badge. Attestation and issuance could originate from any number of trusted sources, such as the artist and/and venue, without requiring users to be running a specific application or platform. Attestation could come from sources such as nostr peers, payment systems, photos or QR codes - or a combination of these using nostr multi-sig. Location proofs could be provided for any valid event, by any signer, with no barriers to entry.
@ -135,6 +135,11 @@ As the bus travels it's route it will generate a series of location updates. One
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` 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`
### Content Field
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.
## Other Notes ## Other Notes
- The value `4326` was selected because it is the default coordinate reference system (CRS) for the GeoJSON specification. If a client or relay wants to use another reference system the GeoJSON spec fully supports including it as a tag. - The value `4326` was selected because it is the default coordinate reference system (CRS) for the GeoJSON specification. If a client or relay wants to use another reference system the GeoJSON spec fully supports including it as a tag.