not just that; it would prevent an app from overwriting a new version of the event it hasn't seen

I should have pointed that out explicitly πŸ˜…: relays SHOULD reject a replaceable event if the passed in timestamp is not the most recent one

e.g.

### creates event at T+0 seconds

"created_at": 1683015000,

"tags": [ ["d", "replace-me" ] ]

### client 1 replaces event at T+10 seconds

"created_at": 1683015010,

"tags": [ ["d", "replace-me" ], "1683015000" ]

### client 2 fails to replace event at T+20 seconds

"created_at": 1683015020,

"tags": [ ["d", "replace-me" ], "1683015000" ]

Reply to this note

Please Login to reply.

Discussion

What would happen if someone gave a time stamp in the past? Or something along those lines.

It feels as though there could be a tree of replaceable events that all reference the most recent timestamp/id and resolving which is the β€œtruth” could be difficult especially when negotiating between relays. I.e. 5 events come in to multiple relays at different times all referencing the most recent timestamp

Just spitballing here

if a timestamp referenced is not that of the current version of the event, the relay rejects it

event forks would be a nightmare and can be done synthetically if someone has that requirement