NIP-22: use nip-20; minor updates

1 files changed, 8 insertions, 8 deletions

diff --git a/22.md b/22.md
index 9ab601d..fb29e6a 100644
--- a/22.md
+++ b/22.md
@@ -8,7 +8,7 @@ Event `created_at` Limits
 
 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.
+If a relay supports this NIP, the relay SHOULD send the client a [NIP-20](20.md) command result saying the event was not stored for the `created_at` timestamp not being within the permitted limits.
 
 Client Behavior
 ---------------
@@ -22,24 +22,24 @@ This NIP formalizes restrictions on event timestamps as accepted by a relay and
 
 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.
+[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 notification 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.
+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.
 
 Keep in mind that there is a use case where a user migrates their old posts onto a new relay. If a relay rejects events that were not recently created, it cannot serve this use case.
 
 
-Python Example
---------------
+Python (pseudocode) Example
+---------------------------
 
 ```python
 import time
 
-TIME = int(time.now)
+TIME = int(time.time())
 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."]')
+  ws.send('["OK", event.id, False, "invalid: the event created_at field is out of the acceptable range (-24h, +15min) for this relay"]')
 ```
+Note: These are just example limits, the relay operator can choose whatever limits they want.