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
a timestamp of the last known event being replaced makes a viable/imperfect system less imperfect imho
as usual, at relays' expense
nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
Are you sure about the cost making it not viable?
All we do as clients it to assemble state. And it is working really well. The cost is not as high as engineers tend to imagine.
What if after six years you’ve followed/unfollowed many thousands of times? You need to fetch all those events every time?
Timestamp where? OTS? I don't get it.
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
