mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-22 00:25:50 -05:00
Remove some examples from nip 32 to keep things concise
This commit is contained in:
Jonathan Staab
parent
992b045aa7
commit
ece0dda45b
77
32.md
77
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", "<pubkey>", "#p"]` - the publisher thinks the given entity is related to `<pubkey>`
|
||||
- `["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", <id>, <relay_url>],
|
||||
["p", <id>, <relay_url>],
|
||||
["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", <relay_url>]
|
||||
],
|
||||
"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", <pubkey1>, <relay_url>],
|
||||
["p", <pubkey2>, <relay_url>]
|
||||
],
|
||||
"content": "<channel_id>",
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
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
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user