From 95d9ba8a215ce4d0443e6a9f8b6026d83f8823f6 Mon Sep 17 00:00:00 2001 From: Ross Bates Date: Wed, 11 Jan 2023 07:36:55 -0600 Subject: [PATCH] Remove section on content field --- 44.md | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/44.md b/44.md index 6c1695b3..eafbccbc 100644 --- a/44.md +++ b/44.md @@ -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