Avoid replaceable events at all costs. They go against the natural order of nostr. Nostr is a huge Event Logging implementation. Having a changeable state without logs is just a lazy way of coding something.
Discussion
Would you count versioned events the same as replaceable events?
Is there a nip for versioned events?
I’m not sure, just shared the idea for a version, because it could retain immutability, and at the same time, maintain updates, client could chose the latest version and can also show an edit history. We could also let people quote or comment on previous versions of a note, that’d be crazy 😂
How do you propose maintaining references throughout modifications?
How would you reference “read this naddr”?
Even nip-33 events are an append-only log, the replaceable effect is just an artificial construct (lol, like ordinals 😂)
Hmm – yeah – actually the more I think about this the less I feel like it solves the problem.
With a large number of relays, it basically becomes impossible to know for certain that you have the latest version of an event. Event with your timestamps. With websockets, you're always going to have to cut off the search (or the wait) for new events matching your filters at some point...
How many relays currently do a good job of signaling when they've exhausted their search and have no more data for you?
all of them, EOSE is basic functionality
like anything in nostr: 1) no guarantees, 2) it's up to clients to be smart enough to not fuck up
but concurrency within a set number of relays is normal/expected behavior
Don't save the state. Create event kinds that modify the state. Clients assemble the state by summing them up.
For instance:
- terrible idea: follow list. We don't know when users are followed and unfollowed, it creates race conditions and we don't actually use the order of the list (there is no need for state consensus).
- great idea: reactions. Separate events instead of a massive reaction state list.
Those parents need to know.
#main 
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
Can you expand on this? I'm not sure I understand what point you're making.
To me, Nostr is a signed messaging system, not an event logging system. The relays are just databases (quite literally). Just as with other databases, sometimes you log stuff other times you overwrite things. Depends on the situation. That’s been Nostr’s approach since the beginning. Kind 0 & 3 are replaceable. Kind 1 isn’t.
The more decentralized a system is, the worse it gets for state storage because clients must achieve consensus on the state at every point in time.
Even though you could choose to have state, the bigger your "micro service" structure is, the bigger the need to save events individually and sync the later. That's what a relay does.