upleb.uk

Public git repos — served from a NIP-34 GRASP relay at git.upleb.uk

summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJeff Thibault <jdthibault2@gmail.com>2022-08-14 11:18:43 -0400
committerGitHub <noreply@github.com>2022-08-14 11:18:43 -0400
commite8a501c08ffb9f99eb823419957cce5cf80a3e44 (patch)
tree3f19d38868fb73f56939b81ca36562b44363d87d
parent6ee98c1bfbe5f4c28fd55bdc835b9a5621e5cab9 (diff)
parent68300c59909a84ffb91695aea24815bf62a1b8e7 (diff)
Merge pull request #1 from Giszmo/nip22
reworded nip-22
-rw-r--r--22.md23
1 files changed, 13 insertions, 10 deletions
diff --git a/22.md b/22.md
index e31f24c..c212802 100644
--- a/22.md
+++ b/22.md
@@ -6,23 +6,25 @@ Event `created_at` Limits
6 6
7`draft` `optional` `author:jeffthibault` 7`draft` `optional` `author:jeffthibault`
8 8
9Relays 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. 9Relays 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).
10 10
11If 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. 11If a relay supports this NIP, the relay SHOULD send the client a `NOTICE` message saying the event was not stored for the `created_at` not being within the permitted limits.
12 12
13Client Behavior 13Client Behavior
14--------------- 14---------------
15 15
16Clients SHOULD use the `supported_nips` field to learn if a relay uses event `created_at` time limits as defined by this NIP. 16Clients 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.
17 17
18Motivation 18Motivation
19---------- 19----------
20 20
21The 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. 21This NIP formalizes restrictions on event timestamps as accepted by a relay and allows clients to be aware of relays that have these restrictions.
22 22
23The 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. 23The 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.
24 24
25A wide adoption of this could create a better UX on clients as well because it would decrease the likelihood of the user seeing events from dates such as 1984 or 2084, which could be confusing. 25[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.
26
27A 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.
26 28
27Python Example 29Python Example
28-------------- 30--------------
@@ -30,9 +32,10 @@ Python Example
30```python 32```python
31import time 33import time
32 34
33UPPER_LIMIT = int(time.now) + 900 # Define upper limit as 15 minutes into the future 35TIME = int(time.now)
34LOWER_LIMIT = int(time.now) - 86400 # Define lower limit as 1 day into the past 36LOWER_LIMIT = TIME - (60 * 60 * 24) # Define lower limit as 1 day into the past
37UPPER_LIMIT = TIME + (60 * 15) # Define upper limit as 15 minutes into the future
35 38
36if event.created_at < LOWER_LIMIT or event.created_at > UPPER_LIMIT: 39if event.created_at not in range(LOWER_LIMIT, UPPER_LIMIT):
37 ws.send('["NOTICE", "The event created_at field is out of the acceptable range for this relay and was not stored."]') 40 ws.send('["NOTICE", "The event created_at field is out of the acceptable range (-24h, +15min) for this relay and was not stored."]')
38``` 41```