Timestamp where? OTS? I don't get it.
I agree in theory, but there's a huge tradeoff on the computation of the current state that makes this non-viable; basically like an RGB/Taro, where client-side computing the entire current state becomes increasingly expensive
thoughts nostr:npub1mygerccwqpzyh9pvp6pv44rskv40zutkfs38t0hqhkvnwlhagp6s3psn5p? I know nostrocket is dealing with pretty much this on nostr infrastructure
Discussion
TL;DR:
include an optional timestamp of the event (the client thinks) it's being replaced on the "d" tag
a way to safeguard that we're not overwriting a newer version this client doesn't know about
context:
nostr:nevent1qqswmcppyexs64vfpn7p3vle6ht9tje95nylja7wl2mhds2d89q0yuq0tsnex
nostr:nevent1qqspgwqzw3vuqxk522amrlkv9znxuq47epsf7z0k4jwfjlzqu9dj6eceh8et0
Did that make sense?
Essentially you are proposing the longest chain for replaceable events, is that right?
no
just saying that to replace an event, a client MAY include a timestamp of what that client *thinks* it's replacing, so that the relay can check if the client has the right state (according to that relay)
it's not perfect, but it's better than how it currently works