Add a note about PREs, update NIP 36 to point to NIP 32

This commit is contained in:
Jonathan Staab 2023-06-07 16:03:05 -07:00
parent 114302517f
commit 363d112e33
2 changed files with 19 additions and 3 deletions

15
32.md
View File

@ -23,9 +23,13 @@ or topics respectively. As with NIP-01, a relay hint SHOULD be included when usi
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 ISO standard or reverse domain name notation. Some examples:
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 ISO standard or reverse domain name notation. Some examples:
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.
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.
- `["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>`
@ -164,3 +168,10 @@ Publishers can self-label by adding `l` tags to their own non-1985 events.
...
}
```
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.

7
36.md
View File

@ -9,12 +9,15 @@ Sensitive Content / Content Warning
The `content-warning` tag enables users to specify if the event's content needs to be approved by readers to be shown.
Clients can hide the content until the user acts on it.
`l` and `L` tags MAY be also be used as defined in [NIP-32](32.md) with the `content-warning` namespace to support
further qualification and querying.
#### Spec
```
tag: content-warning
options:
- [reason]: optional
- [reason]: optional
```
#### Example
@ -26,6 +29,8 @@ options:
"kind": 1,
"tags": [
["t", "hastag"],
["L", "content-warning"],
["l", "reason", "content-warning"],
["content-warning", "reason"] /* reason is optional */
],
"content": "sensitive content with #hastag\n",