nostr/nips
0
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2025-09-01 05:50:47 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity

merge nips 12, 16, 20 and 33 into nip 01 (#703)

Browse Source 
Co-authored-by: Viktor Vsk <me@viktorvsk.com>
This commit is contained in:
fiatjaf_
2023-08-13 13:47:45 -03:00
committed by GitHub
parent a5047326d4
commit 72bb8a128b
17 changed files with 141 additions and 318 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
22.md
View File

@@ -2,13 +2,13 @@ NIP-22
======
Event `created_at` Limits
---------------------------
-------------------------
`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 [NIP-20](20.md) command result 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 an `OK` result saying the event was not stored for the `created_at` timestamp not being within the permitted limits.
Client Behavior
---------------
@@ -22,7 +22,7 @@ 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 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.
_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.