From ece0dda45be1053f673216edb9d6cd8a92035757 Mon Sep 17 00:00:00 2001 From: Jonathan Staab Date: Sat, 17 Jun 2023 09:07:08 -0700 Subject: [PATCH] Remove some examples from nip 32 to keep things concise --- 32.md | 77 ++++++----------------------------------------------------- 1 file changed, 7 insertions(+), 70 deletions(-) diff --git a/32.md b/32.md index b1473859..ddd364ae 100644 --- a/32.md +++ b/32.md @@ -6,11 +6,7 @@ Labeling `draft` `optional` `author:staab` `author:gruruya` `author:s3x-jay` -A label is a `kind 1985` event that is used to label other entities. This supports a number of use cases: - -- Distributed moderation and content recommendations -- Reviews and ratings -- Definition of edges in a graph structure +A label is a `kind 1985` event that is used to label other entities. This supports a number of use cases, from distributed moderation and content recommendations to reviews and ratings. Label Target ---- @@ -26,18 +22,17 @@ Label Tag This NIP introduces a new tag `l` which denotes a label, and a new `L` tag which denotes a label namespace. A label MUST include a mark matching an `L` tag. `L` tags refer to a tag type within nostr, or a nomenclature external to nostr defined either formally or by convention. Any string can be a namespace, but publishers SHOULD -ensure they are unambiguous by using a well-defined namespace (such as an ISO standard) or reverse domain name notation. Some examples: +ensure they are unambiguous by using a well-defined namespace (such as an ISO standard) or reverse domain name notation. Namespaces starting with `#` indicate that the label target should be associated with the label's value. This is a way of attaching standard nostr tags to events, pubkeys, relays, urls, etc. +Some examples: + - `["l", "footstr", "#t"]` - the publisher thinks the given entity should have the `footstr` topic applied. - `["l", "", "#p"]` - the publisher thinks the given entity is related to `` -- `["l", "D005528", "MeSH"]` - ["Foot"](https://meshb.nlm.nih.gov/record/ui?ui=D005528) from NIH's Medical Subject Headings vocabulary -- `["l", "3173435", "GeoNames"]` - [Milan, Italy](https://www.geonames.org/3173435/milan.html) using the GeoNames coding system - `["l", "IT-MI", "ISO-3166-2"]` - Milano, Italy using ISO 3166-2. - `["l", "VI-hum", "com.example.ontology"]` - Violence toward a human being as defined by ontology.example.com. -- `["l", "relay/review", "com.example.ontology"]` - the publisher is leaving a review about a relay, as defined by ontology.example.com. `L` tags containing the label namespaces MUST be included in order to support searching by namespace rather than by a specific tag. The special `ugc` ("user generated content") namespace @@ -65,30 +60,6 @@ explanation of why something was labeled the way it was, should go in the event' Example events -------------- -A single event can apply multiple labels to multiple targets to support mass-tagging. Multiple -namespaces may be used at the same time. - -```json -{ - "kind": 1985, - "tags": [ - ["e", , ], - ["p", , ], - ["t", "chickens"], - ["L", "#t"] - ["L", "ugc"] - ["L", "com.example.labels"] - ["l", "chickens", "#t"], - ["l", "user generated content", "ugc"], - ["l", "permaculture", "com.example.labels"], - ["l", "permies", "com.example.labels"], - ["l", "farming", "com.example.labels"], - ], - "content": "", - ... -} -``` - A suggestion that multiple pubkeys be associated with the `permies` topic. ```json @@ -105,24 +76,7 @@ A suggestion that multiple pubkeys be associated with the `permies` topic. } ``` -A review of a relay, as relates to certain topics, including additional dimensions. The author -is indicating here that `relay_url` is related to the bitcoin topic, but they're not very sure -that's the case. - -```json -{ - "kind": 1985, - "tags": [ - ["L", "#t"], - ["l", "bitcoin", "#t", "{\"quality\": 0.7, \"confidence\": 0.2}"], - ["r", ] - ], - "content": "I think this relay is mostly just bitcoiners.", - ... -} -``` - -A plain review of a relay. +A review of a relay. ```json { @@ -137,24 +91,6 @@ A plain review of a relay. } ``` -A more abstract use case: defining an edge in a graph structure, in this case identifying -a lightning channel that is open between two pubkeys. This just demonstrates the flexibility -this spec provides for overlaying structured metadata on top of nostr. - -```json -{ - "kind": 1985, - "tags": [ - ["L", "my-lightning-nomenclature"], - ["l", "channel", "my-lightning-nomenclature"], - ["p", , ], - ["p", , ] - ], - "content": "", - ... -} -``` - Publishers can self-label by adding `l` tags to their own non-1985 events. ```json @@ -174,7 +110,8 @@ Other Notes When using this NIP to bulk-label many targets at once, events may be deleted and a replacement may be published. We have opted not to use parameterizable/replaceable events for this due to the -complexity in coming up with a standard `d` tag. +complexity in coming up with a standard `d` tag. In order to avoid ambiguity when querying, +publishers SHOULD limit labeling events to a single namespace. Before creating a vocabulary, explore how your use case may have already been designed and imitate that design if possible. Reverse domain name notation is encouraged to avoid