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

Remove section on content field

Browse Source
This commit is contained in:
Ross Bates 2023-01-11 07:36:55 -06:00
parent f76c78a22d
commit 95d9ba8a21
1 changed files with 1 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
44.md
View File

@ -119,7 +119,7 @@ This is a basic example to demonstrate the `kind 4326` data structures and for s
**Decentralized Data Providers**: Support for nostr data types such as `kind 4326` will open up opportunities for nostr relay operators to serve as data service providers. A `kind 4326` event can be any valid geometry including buildings, geofences, and points of interest. This is similar to the concept of linked data URIs, but it's much simpler - `p` can represent any location on earth. Relay operators could charge for custom key/data management services.
**Relay Performance**: By separating data types and content using this approach, relays can route events without the need for content inspection. Notes with `kind 4326` can be forwarded to backend indexing services which respond with new events when conditions are met. As the network grows, some relays may be dedicated solely to routing events based on their type.
**Routable Events**: By separating data types and content using this approach, relays can route events without the need for content inspection. Notes with `kind 4326` can be forwarded to backend indexing services which respond with new events when conditions are met. As the network grows, some relays may be dedicated solely to routing events based on their type.
## Open Issues
@ -135,12 +135,6 @@ 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`
### 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.
*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