rename and rewrite to be more generic

22.md

@@ -1,31 +1,38 @@
 NIP-22
 ======
 
-Unacceptable Event `created_at` time
+Event `created_at` Limits
 ---------------------------
 
 `draft` `optional` `author:jeffthibault`
 
-Relays may support notifying clients that the event they published has an unacceptable `created_at` time. A relay will consider the `created_at` time unacceptable if the `created_at` time is more than **[limit]** before the event was received by the relay (in the past) OR if the `created_at` time is later than the time the event was received by the relay (in the future). 
+Relays may define both upper and lower limits for which they will consider an event's `created_at` time to be acceptable if it is within those limits. Both the upper and lower limits MUST be unix timestamps to match the format of the event's `created_at` field. The upper limit restricts how far into the future an event's `created_at` time can be set to and the lower limit restricts how far into the past an event's `created_at` time can be set to.  
 
-If a relay supports this NIP, the relay SHOULD send the client a `NOTICE` message saying the event was not stored because the `created_at` time was unacceptable.
+If a relay supports this NIP, the relay SHOULD send the client a `NOTICE` message saying the event was not stored when the `created_at` time is not within the upper and lower limits.
 
 Client Behavior
 ---------------
 
-Clients SHOULD use the `supported_nips` field to learn if a relay supports event `created_at` time checks.
+Clients SHOULD use the `supported_nips` field to learn if a relay uses event `created_at` time limits as defined by this NIP.
 
 Motivation
 ----------
 
-The motivation for this NIP is to prevent clients from saying they published an event *significantly* earlier than they actually did or saying they published an event in the future.
+The motivation for this NIP is to formalize a way for relays to restrict event timestamps to times they deem to be acceptable and allow clients to be aware of relays that have these restrictions.
 
-The event `created_at` field is just a unix timestamp (integer) so one could set it to a time in the past or future. For example, the `created_at` field could be set to a time 10 years ago even though it was created today and it could still be a valid event. One could also set the `created_at` field to a time 10 years in the future and it could still be a valid event. This NIP aims to set a maximum amount of time elapsed between when an event was created and when it was *actually* published and prevent events from being from the future.
+The event `created_at` field is just a unix timestamp and can be set to a time in the past or future. For example, the `created_at` field can be set to a time 20 years ago even though it was created today and still be a valid event. It can also be set to a time 20 years in the future and still be a valid event. This NIP aims to define a way for relays that do not want to store events with *any* timestamp to set their own restrictions.
 
-Relay Logic
+A wide adoption of this could create a better UX on clients as well because it would decrease the liklihood of the user seeing events from dates such as 1984 or 2084, which could be confusing.
------------
 
-```
+Python Example
-if time.now - event.created_at > limit OR event.created_at > time.now:
+--------------
-  send NOTICE
+
+```python
+import time
+
+UPPER_LIMIT = int(time.now) + 900 # Define upper limit as 15 minutes into the future
+LOWER_LIMIT = int(time.now) - 86400 # Define lower limit as 1 day into the past
+
+if event.created_at < LOWER_LIMIT or event.created_at > UPPER_LIMIT:
+  ws.send('["NOTICE", "The event created_at field is out of the acceptable range for this relay and was not stored."]')
 ```