upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
path: root/32.md
diff options
context:
space:
mode:
authorJon Staab <shtaab@gmail.com>2023-11-10 08:13:04 -0800
committerfiatjaf_ <fiatjaf@gmail.com>2023-11-12 13:46:01 -0300
commitb6c7a255102a65c4978b465a85f124e910e82a2d (patch)
tree003c372f02f671a02815070b4260320531557133 /32.md
parent8e2f3aa60a293dd65d5c42e9d61b9fb9114f2717 (diff)
Clarify NIP 32
Diffstat (limited to '32.md')
-rw-r--r--32.md105
1 files changed, 68 insertions, 37 deletions
diff --git a/32.md b/32.md
index c5c6272..f8dc002 100644
--- a/32.md
+++ b/32.md
@@ -6,40 +6,38 @@ Labeling
6 6
7`draft` `optional` `author:staab` `author:gruruya` `author:s3x-jay` 7`draft` `optional` `author:staab` `author:gruruya` `author:s3x-jay`
8 8
9A label is a `kind 1985` event that is used to label other entities. This supports a number of use cases, including distributed moderation, collection management, license assignment, and content classification. 9A label is a `kind 1985` event that is used to label other entities. This supports a number of use cases,
10including distributed moderation, collection management, license assignment, and content classification.
10 11
11Label Target 12This NIP introduces two new tags:
12----
13 13
14The label event MUST include one or more tags representing the object or objects being 14- `L` denotes a label namespace
15labeled: `e`, `p`, `a`, `r`, or `t` tags. This allows for labeling of events, people, relays, 15- `l` denotes a label
16or topics respectively. As with NIP-01, a relay hint SHOULD be included when using `e` and
17`p` tags.
18 16
19Label Tag 17Label Namespace Tag
20---- 18----
21 19
22This NIP introduces a new tag `l` which denotes a label, and a new `L` tag which denotes a label namespace. 20An `L` tag can be any string, but publishers SHOULD ensure they are unambiguous by using a well-defined namespace
23A label MUST include a mark matching an `L` tag. `L` tags refer to a tag type within nostr, or a nomenclature 21(such as an ISO standard) or reverse domain name notation.
24external to nostr defined either formally or by convention. Any string can be a namespace, but publishers SHOULD 22
25ensure they are unambiguous by using a well-defined namespace (such as an ISO standard) or reverse domain name notation. 23`L` tags are REQUIRED in order to support searching by namespace rather than by a specific tag. The special `ugc`
24("user generated content") namespace MAY be used when the label content is provided by an end user.
26 25
27Namespaces starting with `#` indicate that the label target should be associated with the label's value. 26`L` tags starting with `#` indicate that the label target should be associated with the label's value.
28This is a way of attaching standard nostr tags to events, pubkeys, relays, urls, etc. 27This is a way of attaching standard nostr tags to events, pubkeys, relays, urls, etc.
29 28
30Some examples: 29Label Tag
30----
31 31
32- `["l", "footstr", "#t"]` - the publisher thinks the given entity should have the `footstr` topic applied. 32An `l` tag's value can be any string. `l` tags MUST include a `mark` matching an `L` tag value in the same event.
33- `["l", "<pubkey>", "#p"]` - the publisher thinks the given entity is related to `<pubkey>`
34- `["l", "IT-MI", "ISO-3166-2"]` - Milano, Italy using ISO 3166-2.
35- `["l", "VI-hum", "com.example.ontology"]` - Violence toward a human being as defined by ontology.example.com.
36 33
37`L` tags containing the label namespaces MUST be included in order to support searching by 34Label Target
38namespace rather than by a specific tag. The special `ugc` ("user generated content") namespace 35----
39MAY be used when the label content is provided by an end user.
40 36
41`l` and `L` tags MAY be added to other event kinds to support self-reporting. For events 37The label event MUST include one or more tags representing the object or objects being
42with a kind other than 1985, labels refer to the event itself. 38labeled: `e`, `p`, `a`, `r`, or `t` tags. This allows for labeling of events, people, relays,
39or topics respectively. As with NIP-01, a relay hint SHOULD be included when using `e` and
40`p` tags.
43 41
44Content 42Content
45------- 43-------
@@ -47,6 +45,12 @@ Content
47Labels should be short, meaningful strings. Longer discussions, such as for a review, or an 45Labels should be short, meaningful strings. Longer discussions, such as for a review, or an
48explanation of why something was labeled the way it was, should go in the event's `content` field. 46explanation of why something was labeled the way it was, should go in the event's `content` field.
49 47
48Self-Reporting
49-------
50
51`l` and `L` tags MAY be added to other event kinds to support self-reporting. For events
52with a kind other than 1985, labels refer to the event itself.
53
50Example events 54Example events
51-------------- 55--------------
52 56
@@ -60,39 +64,61 @@ A suggestion that multiple pubkeys be associated with the `permies` topic.
60 ["l", "permies", "#t"], 64 ["l", "permies", "#t"],
61 ["p", <pubkey1>, <relay_url>], 65 ["p", <pubkey1>, <relay_url>],
62 ["p", <pubkey2>, <relay_url>] 66 ["p", <pubkey2>, <relay_url>]
63 ], 67 ]
64 "content": "",
65 ...
66} 68}
67``` 69```
68 70
69A review of a relay. 71A report flagging violence toward a human being as defined by ontology.example.com.
70 72
71```json 73```json
72{ 74{
73 "kind": 1985, 75 "kind": 1985,
74 "tags": [ 76 "tags": [
75 ["L", "com.example.ontology"], 77 ["L", "com.example.ontology"],
76 ["l", "relay/review", "com.example.ontology"], 78 ["l", "VI-hum", "com.example.ontology"],
77 ["r", <relay_url>], 79 ["p", <pubkey1>, <relay_url>],
78 ["rating", "0.1"] 80 ["p", <pubkey2>, <relay_url>]
81 ]
82}
83```
84
85A moderation suggestion for a chat event.
86
87```json
88{
89 "kind": 1985,
90 "tags": [
91 ["L", "nip28.moderation"],
92 ["l", "approve", "nip28.moderation"],
93 ["e", <kind40_event_id>, <relay_url>]
79 ], 94 ],
80 "content": "This relay is full of mean people.",
81 ...
82} 95}
83``` 96```
84 97
85Publishers can self-label by adding `l` tags to their own non-1985 events. 98Assignment of a license to an event.
99
100```json
101{
102 "kind": 1985,
103 "tags": [
104 ["L", "license"],
105 ["l", "MIT", "license"],
106 ["e", <event_id>, <relay_url>]
107 ],
108}
109```
110
111Publishers can self-label by adding `l` tags to their own non-1985 events. In this case, the kind 1 event's author
112is labeling their note as being related to Milan, Italy using ISO 3166-2.
86 113
87```json 114```json
88{ 115{
89 "kind": 1, 116 "kind": 1,
90 "tags": [ 117 "tags": [
91 ["L", "com.example.ontology"], 118 ["L", "ISO-3166-2"],
92 ["l", "IL-frd", "com.example.ontology"] 119 ["l", "IT-MI", "ISO-3166-2"]
93 ], 120 ],
94 "content": "Send me 100 sats and I'll send you 200 back", 121 "content": "It's beautiful here in Milan!",
95 ...
96} 122}
97``` 123```
98 124
@@ -115,3 +141,8 @@ Vocabularies MAY choose to fully qualify all labels within a namespace (for exam
115formal vocabularies that should not be confused with another namespace when querying 141formal vocabularies that should not be confused with another namespace when querying
116without an `L` tag. For these vocabularies, all labels SHOULD include the namespace 142without an `L` tag. For these vocabularies, all labels SHOULD include the namespace
117(rather than mixing qualified and unqualified labels). 143(rather than mixing qualified and unqualified labels).
144
145A good heuristic for whether a use case fits this NIP is whether labels would ever be unique.
146For example, many events might be labeled with a particular place, topic, or pubkey, but labels
147with specific values like "John Doe" or "3.18743" are not labels, they are values, and should
148be handled in some other way.