1 files changed, 3 insertions, 3 deletions
diff --git a/22.md b/22.md
index 2172519..f595ebf 100644
--- a/22.md
+++ b/22.md
@@ -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.

diff --git a/22.md b/22.md index 2172519..f595ebf 100644 --- a/22.md +++ b/22.md
@@ -2,13 +2,13 @@ NIP-22
2	======	2	======
3		3
4	Event `created_at` Limits	4	Event `created_at` Limits
5	---------------------------	5	-------------------------
6		6
7	`draft` `optional` `author:jeffthibault` `author:Giszmo`	7	`draft` `optional` `author:jeffthibault` `author:Giszmo`
8		8
9	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).	9	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).
10		10
11	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.	11	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.
12		12
13	Client Behavior	13	Client Behavior
14	---------------	14	---------------
@@ -22,7 +22,7 @@ This NIP formalizes restrictions on event timestamps as accepted by a relay and
22		22
23	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.	23	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.
24		24
25	[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.	25	_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.
26		26
27	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.	27	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.
28		28