mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-13 19:06:24 +00:00
148 lines
3.8 KiB
Markdown
148 lines
3.8 KiB
Markdown
NIP-32
|
|
======
|
|
|
|
Labeling
|
|
---------
|
|
|
|
`draft` `optional` `author:staab` `author:gruruya`
|
|
|
|
A label is a `kind 1985` note 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
|
|
|
|
This NIP does not supersede NIP-56, which supports reporting content for the purpose of
|
|
direct moderation, in order to comply with laws or app store requirements. "Moderation"
|
|
as defined by this NIP is only relative to user preferences and should be interpreted
|
|
with the social graph in view to provide a better user experience.
|
|
|
|
Label Target
|
|
----
|
|
|
|
The label event MUST include one or more tags representing the object or objects being
|
|
labeled: `e`, `p`, `r`, or `t` tags. This allows for labeling of events, people, relays,
|
|
or topics respectively.
|
|
|
|
Label Tag
|
|
----
|
|
|
|
This NIP introduces a new tag `l` which denotes a label. A label MAY be an unqualified string indicating the type of content based on convention, a qualified string referring to a tag type within nostr, or a qualified string referring to a nomenclature external to nostr. Some examples:
|
|
|
|
- `review` - the publisher is leaving a review about the given entity.
|
|
- `#t/footstr` - the publisher thinks the given entity should have the `footstr` topic applied.
|
|
- `#p/<pubkey>` - the publisher things the given entity should be tagged with with `<pubkey>`
|
|
- `MeSH/D005528` - ["Foot"](https://meshb.nlm.nih.gov/record/ui?ui=D005528) from NIH's Medical Subject Headings vocabulary
|
|
- `GeoNames/3173435` - [Milan, Italy](https://www.geonames.org/3173435/milan.html) using the GeoNames coding system
|
|
- `ISO-3166-2/IT-MI` - Milano, Italy using ISO 3166-2.
|
|
|
|
As much as possible, fully-qualified labels should be used.
|
|
|
|
Other Tags
|
|
-----
|
|
|
|
The label event MAY include a `quality` tag with a value of 0 to 1. This allows for an
|
|
absolute, granular scale that can be represented in any way (5 stars, color scale, etc).
|
|
|
|
The label event MAY include a `confidence` tag with a value of 0 to 1. This indicates the certainty which the author has about their rating.
|
|
|
|
Example events
|
|
--------------
|
|
|
|
A report that an event contains nudity.
|
|
|
|
```json
|
|
{
|
|
"kind": 1985,
|
|
"tags": [
|
|
["e", <id>],
|
|
["l", "nudity"]
|
|
],
|
|
"content": "",
|
|
...
|
|
}
|
|
```
|
|
|
|
A single event can apply multiple labels to multiple targets to support mass-tagging.
|
|
|
|
```json
|
|
{
|
|
"kind": 1985,
|
|
"tags": [
|
|
["e", <id>],
|
|
["p", <id>],
|
|
["t", "chickens"],
|
|
["l", "permaculture"],
|
|
["l", "permies"],
|
|
["l", "farming"]
|
|
],
|
|
"content": "",
|
|
...
|
|
}
|
|
```
|
|
|
|
A suggestion that multiple pubkeys be associated with the `permies` topic.
|
|
|
|
```json
|
|
{
|
|
"kind": 1985,
|
|
"tags": [
|
|
["l", "#t/permies"],
|
|
["p", <pubkey1>],
|
|
["p", <pubkey2>]
|
|
],
|
|
"content": "",
|
|
...
|
|
}
|
|
```
|
|
|
|
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/bitcoin"],
|
|
["r", <relay_url>],
|
|
["quality", 0.7],
|
|
["confidence", 0.2]
|
|
],
|
|
"content": "I think this relay is mostly just bitcoiners.",
|
|
...
|
|
}
|
|
```
|
|
|
|
A plain review of a relay.
|
|
|
|
```json
|
|
{
|
|
"kind": 1985,
|
|
"tags": [
|
|
["l", "review"],
|
|
["r", <relay_url>],
|
|
["quality", 0.1]
|
|
],
|
|
"content": "This relay is full of mean people.",
|
|
...
|
|
}
|
|
```
|
|
|
|
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", "lightning/channel"],
|
|
["p", <pubkey1>],
|
|
["p", <pubkey2>]
|
|
],
|
|
"content": "<channel_id>",
|
|
...
|
|
}
|
|
```
|