Update 27.md

27.md

@@ -0,0 +1,91 @@
+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.

README.md

@@ -20,6 +20,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
 - [NIP-16: Event Treatment](16.md)
 - [NIP-22: Event created_at Limits](22.md)
 - [NIP-25: Reactions](25.md)
+- [NIP-27: Restricted events](27.md)
 
 ## Event Kinds