delete NIP-22 (#897)

This commit is contained in:
fiatjaf_ 2023-12-01 13:54:12 -03:00 committed by GitHub
parent 0874eab3c9
commit d67988e64e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 2 additions and 48 deletions

4
11.md
View File

@ -131,9 +131,9 @@ This should only be set to `true` when users are expected to know the relay poli
to write to it -- like belonging to a special pubkey-based whitelist or writing only events of
a specific niche kind or content. Normal anti-spam heuristics, for example, do not qualify.
- `created_at_lower_limit`: 'created_at' lower limit as defined in [NIP-22](22.md)
- `created_at_lower_limit`: 'created_at' lower limit
- `created_at_upper_limit`: 'created_at' upper limit as defined in [NIP-22](22.md)
- `created_at_upper_limit`: 'created_at' upper limit
### Event Retention

45
22.md
View File

@ -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.

View File

@ -38,7 +38,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-18: Reposts](18.md)
- [NIP-19: bech32-encoded entities](19.md)
- [NIP-21: `nostr:` URI scheme](21.md)
- [NIP-22: Event `created_at` Limits](22.md)
- [NIP-23: Long-form Content](23.md)
- [NIP-24: Extra metadata fields and tags](24.md)
- [NIP-25: Reactions](25.md)