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 events:

[
  "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:

[
  "REQ",
  "<subscriptionId>",
  {
    "#ch": ["/nostr/social"]
  }
]

Use Cases

Subreddit/IRC-like channels (e.g. { "#ch": ["r/oldschoolcool"] }) over Nostr.
Forums. (e.g. General/Support subforum at itguys.com forum { "#fr": ["itguys.com"], "#sb": ["General/Support"] })
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.
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.
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.
Live events can take advantage of ephemeral events and events with restricted tags for exclusivity during the event.
Smart contracts may communicate with individual clients using events with restricted tags.
Developers debugging in Nostr can use events with restricted tags to avoid spamming others in public relays.

Notes

Events with restricted tags are public and offer no privacy.

3.1 KiB Raw Blame History