nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-09-19 22:35:50 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity

Remove some examples from nip 32 to keep things concise

Browse Source
This commit is contained in:
Jonathan Staab 2023-06-17 09:07:08 -07:00
parent 992b045aa7
commit ece0dda45b
1 changed files with 7 additions and 70 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
32.md
View File

@ -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