5.4 KiB
NIP-32
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
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. As with NIP-01, a relay hint SHOULD be included when using e
and
p
tags.
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. Some examples:
["l", "footstr", "#t"]
- the publisher thinks the given entity should have thefootstr
topic applied.["l", "<pubkey>", "#p"]
- the publisher things the given entity should be tagged with with<pubkey>
["l", "D005528", "MeSH"]
- "Foot" from NIH's Medical Subject Headings vocabulary["l", "3173435", "GeoNames"]
- Milan, Italy using the GeoNames coding system["l", "IT-MI", "ISO-3166-2"]
- Milano, Italy using ISO 3166-2.["l", "relay", "review"]
- the publisher is leaving a review about a relay.
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
MAY be used when the label content is provided by an end user.
l
and L
tags MAY be added to other event kinds to support self-reporting. For events
with a kind other than 1985, labels refer to the event itself.
Label Annotations
A label tag MAY include a 4th positional element detailing extra information about the label in question. This string
should be a url-encoded list of key/value pairs, for example quality=1&confidence=1
. Any key MAY be used, but the
following are recommended:
quality
may have 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).confidence
may have a value of 0 to 1. This indicates the certainty which the author has about their rating.context
may be a comma-separated list of urls (including NIP-21 urls) indicating other context that should be considered when interpreting labels.
Content
Labels should be short, meaningful strings. Longer discussions, such as for a review, or an
explanation of why something was labeled the way it was should go in the event's content
field.
Example events
A report that an event contains nudity. Note that NIP 56 is preferred for reporting content to clients, while labels are recommended for supporting distributed content moderation use cases.
{
"kind": 1985,
"tags": [
["L", "report"],
["l", "nudity", "report"],
["e", <id>, <relay_url>]
],
"content": "",
...
}
A single event can apply multiple labels to multiple targets to support mass-tagging. Multiple namespaces may be used at the same time.
{
"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.
{
"kind": 1985,
"tags": [
["L", "#t"],
["l", "permies", "#t"],
["p", <pubkey1>, <relay_url>],
["p", <pubkey2>, <relay_url>]
],
"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.
{
"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.
{
"kind": 1985,
"tags": [
["L", "review"],
["l", "relay", "review", "quality=0.1"],
["r", <relay_url>]
],
"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.
{
"kind": 1985,
"tags": [
["L", "my-lightning-nomenclature"],
["l", "channel", "my-lightning-nomenclature"],
["p", <pubkey1>, <relay_url>],
["p", <pubkey2>, <relay_url>]
],
"content": "<channel_id>",
...
}