nips/27.md

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.