From f51ce9dc0efaf61f39a76e112c310a9f58af1c87 Mon Sep 17 00:00:00 2001 From: Jeff Thibault Date: Fri, 22 Jul 2022 11:50:07 -0400 Subject: [PATCH 1/8] add nip22: unacceptable event created_at field --- 22.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 22.md diff --git a/22.md b/22.md new file mode 100644 index 00000000..1cd21204 --- /dev/null +++ b/22.md @@ -0,0 +1,23 @@ +NIP-22 +====== + +Unacceptable Event `created_at` time +--------------------------- + +`draft` `optional` `author:jeffthibault` + +Relays may support notifying clients that the event they published has an unacceptable `created_at` time. A relay will will consider the `created_at` time unacceptable if the `created_at` time is more than **[limit]** before the event was received by the relay. + +If a relay supports this NIP, the relay SHOULD send the client a `NOTICE` message saying the event was not stored because the timestamp was too old. + +Client Behavior +--------------- + +Clients SHOULD use the `supported_nips` field to learn if a relay supports event `created_at` checks. + +Motivation +---------- + +The motivation for this NIP is to prevent clients from saying they published an event *significantly* earlier than they actually did. + +The event `created_at` field is just a unix timestamp (integer) so one could set it to a time in the past. 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. This NIP aims to set a maximum amount of time elapsed between when an event was created and when it was *actually* published. From 8bef0e9d79ebb4b11f8fd2bea11dc8f1668bc9d0 Mon Sep 17 00:00:00 2001 From: Jeff Thibault Date: Fri, 22 Jul 2022 12:45:14 -0400 Subject: [PATCH 2/8] add that events from future are unacceptable --- 22.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/22.md b/22.md index 1cd21204..df5da822 100644 --- a/22.md +++ b/22.md @@ -6,18 +6,18 @@ Unacceptable Event `created_at` time `draft` `optional` `author:jeffthibault` -Relays may support notifying clients that the event they published has an unacceptable `created_at` time. A relay will will consider the `created_at` time unacceptable if the `created_at` time is more than **[limit]** before the event was received by the relay. +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). -If a relay supports this NIP, the relay SHOULD send the client a `NOTICE` message saying the event was not stored because the timestamp was too old. +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. Client Behavior --------------- -Clients SHOULD use the `supported_nips` field to learn if a relay supports event `created_at` checks. +Clients SHOULD use the `supported_nips` field to learn if a relay supports event `created_at` time checks. Motivation ---------- -The motivation for this NIP is to prevent clients from saying they published an event *significantly* earlier than they actually did. +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 event `created_at` field is just a unix timestamp (integer) so one could set it to a time in the past. 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. This NIP aims to set a maximum amount of time elapsed between when an event was created and when it was *actually* published. +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. From d1b6bdb18e522fa34ff7cfec3d56318da596fdff Mon Sep 17 00:00:00 2001 From: Jeff Thibault Date: Fri, 22 Jul 2022 12:53:54 -0400 Subject: [PATCH 3/8] add relay logic --- 22.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/22.md b/22.md index df5da822..0192307d 100644 --- a/22.md +++ b/22.md @@ -21,3 +21,11 @@ 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 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. + +Relay Logic +----------- + +``` +if time.now - event.created_at > limit OR event.created_at > time.now: + send NOTICE +``` From ef0f8a1186631dd7808614960cd11168139aa28e Mon Sep 17 00:00:00 2001 From: Jeff Thibault Date: Sat, 13 Aug 2022 13:52:14 -0400 Subject: [PATCH 4/8] rename and rewrite to be more generic --- 22.md | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/22.md b/22.md index 0192307d..f62aa4e6 100644 --- a/22.md +++ b/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. -``` -if time.now - event.created_at > limit OR event.created_at > time.now: - send NOTICE +Python Example +-------------- + +```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."]') ``` From f5852fda8334c10bc72402f99ffabe093ce1b899 Mon Sep 17 00:00:00 2001 From: Jeff Thibault Date: Sat, 13 Aug 2022 13:54:28 -0400 Subject: [PATCH 5/8] add nip link to readme --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index acf86894..e1858a97 100644 --- a/README.md +++ b/README.md @@ -18,6 +18,7 @@ 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) ## Event Kinds From 6ee98c1bfbe5f4c28fd55bdc835b9a5621e5cab9 Mon Sep 17 00:00:00 2001 From: Jeff Thibault Date: Sat, 13 Aug 2022 14:08:14 -0400 Subject: [PATCH 6/8] spelling nit --- 22.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/22.md b/22.md index f62aa4e6..e31f24c7 100644 --- a/22.md +++ b/22.md @@ -22,7 +22,7 @@ The motivation for this NIP is to formalize a way for relays to restrict event t 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. -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. +A 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. Python Example -------------- From 68300c59909a84ffb91695aea24815bf62a1b8e7 Mon Sep 17 00:00:00 2001 From: Leo Wandersleb Date: Sat, 13 Aug 2022 21:50:38 -0400 Subject: [PATCH 7/8] reword nip22, mention replaceable events --- 22.md | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/22.md b/22.md index e31f24c7..c212802a 100644 --- a/22.md +++ b/22.md @@ -6,23 +6,25 @@ Event `created_at` Limits `draft` `optional` `author:jeffthibault` -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. +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 when the `created_at` time is not within the upper and lower limits. +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` not being within the permitted limits. Client Behavior --------------- -Clients SHOULD use the `supported_nips` field to learn if a relay uses event `created_at` time limits as defined by this NIP. +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 ---------- -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. +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. 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. +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. -A 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. +[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 -------------- @@ -30,9 +32,10 @@ Python Example ```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 +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 < 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."]') +if event.created_at not in range(LOWER_LIMIT, UPPER_LIMIT): + ws.send('["NOTICE", "The event created_at field is out of the acceptable range (-24h, +15min) for this relay and was not stored."]') ``` From 903cc0992eedd752a688ce11c77d8a7bea57ae82 Mon Sep 17 00:00:00 2001 From: Jeff Thibault Date: Sun, 14 Aug 2022 11:26:39 -0400 Subject: [PATCH 8/8] add Giszmo, add comment in code example --- 22.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/22.md b/22.md index c212802a..e4cea514 100644 --- a/22.md +++ b/22.md @@ -4,11 +4,11 @@ NIP-22 Event `created_at` Limits --------------------------- -`draft` `optional` `author:jeffthibault` +`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` not being within the permitted limits. +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 --------------- @@ -37,5 +37,6 @@ 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."]') ```