From d67988e64ee3c0a0df859ad557aa26fb7844f11e Mon Sep 17 00:00:00 2001 From: fiatjaf_ Date: Fri, 1 Dec 2023 13:54:12 -0300 Subject: delete NIP-22 (#897) --- 22.md | 45 --------------------------------------------- 1 file changed, 45 deletions(-) delete mode 100644 22.md (limited to '22.md') diff --git a/22.md b/22.md deleted file mode 100644 index 06af493..0000000 --- a/22.md +++ /dev/null @@ -1,45 +0,0 @@ -NIP-22 -====== - -Event `created_at` Limits -------------------------- - -`draft` `optional` - -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 an `OK` result 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_ can behave rather unexpectedly 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. - -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 (pseudocode) Example ---------------------------- - -```python -import time - -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): - 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. -- cgit v1.2.3