mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-14 03:16:22 +00:00
92 lines
3.1 KiB
Markdown
92 lines
3.1 KiB
Markdown
NIP-27
|
|
======
|
|
|
|
Restricted Tags
|
|
---------------
|
|
|
|
`draft` `optional` `author:cameri`
|
|
|
|
This NIP extends the `<filters>` object described in `NIP-01` to contain
|
|
arbitrary two-letter tags (known as restricted tags) prefixed by `#`, allowing
|
|
for events with restricted tags to be queried. Any two-letter key prefixed by
|
|
`#` is a restricted tag query and must be an array of strings.
|
|
|
|
The filter condition matches an event if and only if all of the restricted tags
|
|
in the event are also present in a `<filters>` object. As such, relays should not
|
|
forward events with restricted tags to clients without a strictly matching filter.
|
|
|
|
A client wishing to use restricted tags should only send events with restricted
|
|
tags to relays that explicitly support NIP-27.
|
|
|
|
## Events
|
|
|
|
Clients wishing to send an event with a restricted tag may include one or more
|
|
two-letter tags with a value set to an arbitrary string.
|
|
|
|
Suppose that Alice wants to send an event with the restricted tag `#ch`. The value
|
|
of the `#ch` restricted tag is the following string: `/nostr/social`
|
|
|
|
Alice would construct the following message and send it to her favorite relay
|
|
which happens to support restricted tags:
|
|
|
|
```json
|
|
[
|
|
"EVENT",
|
|
{
|
|
"id": "<id>",
|
|
"pubkey": "<Alice's pubkey>",
|
|
"created_at": 1231469640,
|
|
"content": "Let's get the conversation started",
|
|
"tags": [
|
|
["ch", "/nostr/social"],
|
|
],
|
|
"sig": "<sig>"
|
|
}
|
|
]
|
|
```
|
|
|
|
## Subscriptions
|
|
|
|
Clients wishing to subscribe to events with restricted tags MUST include a filter
|
|
that matches all of the restricted tags in said events.
|
|
|
|
Suppose that Bob and Charlie both share Alice's interest and would like to stay
|
|
up to date. Both would construct the following message to subscribe:
|
|
|
|
```json
|
|
[
|
|
"REQ",
|
|
"<subscriptionId>",
|
|
{
|
|
"#ch": ["/nostr/social"]
|
|
}
|
|
]
|
|
```
|
|
|
|
# Use Cases
|
|
|
|
1. Subreddit/IRC-like channels (e.g. `{ "#ch": ["r/oldschoolcool"] }`) over Nostr.
|
|
2. Forums. (e.g. General/Support subforum at itguys.com forum
|
|
`{ "#fr": ["itguys.com"], "#sb": ["General/Support"] }`)
|
|
3. Clients wishing to filter out all the noise from the broad public events may
|
|
choose to only subscribe to events with restricted tags. Apps/games/bots leveraging
|
|
Nostr may prefer communicating using NIP-27 to namespace their communications.
|
|
4. A restricted tag with a hard-to-guess value can be used for increased isolation
|
|
in communications without the expectation of privacy. A "channel-hopping" algorithm
|
|
shared by clients may improve isolation in this scenario.
|
|
5. Two or more parties may initiate contact publicly using Direct Messaging to then
|
|
upgrade their communications to using events with restricted tags with a hard-to-guess
|
|
value before continuing their exchange. Parties can re-negotiate a new hard-to-guess
|
|
value at any point.
|
|
6. Live events can take advantage of ephemeral events and events with restricted
|
|
tags for exclusivity during the event.
|
|
7. Smart contracts may communicate with individual clients using events with
|
|
restricted tags.
|
|
8. Developers debugging in Nostr can use events with restricted tags to avoid spamming
|
|
others in public relays.
|
|
|
|
|
|
# Notes
|
|
|
|
1. Events with restricted tags are public and offer no privacy.
|