mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-11-09 22:09:06 -05:00
177 lines
5.3 KiB
Markdown
177 lines
5.3 KiB
Markdown
NIP-32
|
|
======
|
|
|
|
Labeling
|
|
---------
|
|
|
|
`draft` `optional` `author:staab` `author:gruruya` `author:s3x-jay`
|
|
|
|
A label is a `kind 1985` (regular) event or `kind 32144` (replaceable) 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.
|
|
|
|
Any number of targets may be included when using a kind `1985` non-replaceable event. If kind
|
|
`32144` is preferred, the event MUST have a single target tag, and its value MUST also be the
|
|
value of the `d` tag.
|
|
|
|
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 the `footstr` topic applied.
|
|
- `["l", "<pubkey>", "#p"]` - the publisher things the given entity should be tagged with with `<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", "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.
|
|
|
|
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.
|
|
|
|
Content
|
|
-------
|
|
|
|
`l` tags 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.
|
|
|
|
```json
|
|
{
|
|
"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.
|
|
|
|
```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
|
|
{
|
|
"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.
|
|
|
|
```json
|
|
{
|
|
"kind": 1985,
|
|
"tags": [
|
|
["L", "#t"],
|
|
["l", "bitcoin", "#t"],
|
|
["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"],
|
|
["l", "relay", "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", "my-lightning-nomenclature"],
|
|
["l", "channel", "my-lightning-nomenclature"],
|
|
["p", <pubkey1>, <relay_url>],
|
|
["p", <pubkey2>, <relay_url>]
|
|
],
|
|
"content": "<channel_id>",
|
|
...
|
|
}
|
|
```
|