Update 27.md

NIP-22: event created_at limits

22.md

@@ -0,0 +1,42 @@
+NIP-22
+======
+
+Event `created_at` Limits
+---------------------------
+
+`draft` `optional` `author:jeffthibault` `author:Giszmo`
+
+Relays may define both upper and lower limits within which they will consider an event's `created_at` to be acceptable. Both the upper and lower limits MUST be unix timestamps in seconds as defined in [NIP-01](01.md).
+
+If a relay supports this NIP, the relay SHOULD send the client a `NOTICE` message saying the event was not stored for the `created_at` timestamp not being within the permitted limits.
+
+Client Behavior
+---------------
+
+Clients SHOULD use the [NIP-11](11.md) `supported_nips` field to learn if a relay uses event `created_at` time limits as defined by this NIP.
+
+Motivation
+----------
+
+This NIP formalizes restrictions on event timestamps as accepted by a relay and allows clients to be aware of relays that have these restrictions.
+
+The event `created_at` field is just a unix timestamp and can be set to a time in the past or future. Relays accept and share events dated to 20 years ago or 50,000 years in the future. This NIP aims to define a way for relays that do not want to store events with *any* timestamp to set their own restrictions.
+
+[Replaceable events](16.md#replaceable-events) can behave rather unexpected if the user wrote them - or tried to write them - with a wrong system clock. Persisting an update with a backdated system now would result in the update not getting persisted without a `NOTICE` and if they did the last update with a forward dated system, they will again fail to do another update with the now correct time.
+
+A wide adoption of this nip could create a better user experience as it would decrease the amount of events that appear wildly out of order or even from impossible dates in the distant past or future.
+
+Python Example
+--------------
+
+```python
+import time
+
+TIME = int(time.now)
+LOWER_LIMIT = TIME - (60 * 60 * 24) # Define lower limit as 1 day into the past
+UPPER_LIMIT = TIME + (60 * 15)      # Define upper limit as 15 minutes into the future
+
+if event.created_at not in range(LOWER_LIMIT, UPPER_LIMIT):
+  # NOTE: This is one example of a notice message. Relays can change this to notify clients however they like.
+  ws.send('["NOTICE", "The event created_at field is out of the acceptable range (-24h, +15min) for this relay and was not stored."]')
+```

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

@@ -18,7 +18,9 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh
 - [NIP-14: Subject tag in text events.](14.md)
 - [NIP-15: End of Stored Events Notice](15.md)
 - [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