Do you consider replaceable events an overhead?
Discussion
Yes, they are very annoying to deal with, but that is made simpler by the fact that they are not expected to be displayed in realtime in a constantly updating feed that may or may not be cached locally and/or by relays.
Kind 1 notes are easy to deal with in this "live" scenario: they either exist or they don't. All events always have the same id, so it's easy to match and cache and I'm probably forgetting a dozen other arguments that me and others have given in the past against having editable events.
So do you prefer that we just delete the event and send a new one with dates in the past? I initially didn't want to do that because it would create duplicated events in the feed of clients that don't implement deletion yet.
I think that is bad too, accepting the fact that things don't change is probably the best way, but seems much simpler to implement and not very harmful to clients that don't implement it.
Probably the most honest UI, if you want, would be to have a "nuke" button that tries to delete everything, but decouple that action from the act of creating a new note. Let people manually delete and then make a new one.
+1 for decoupling. You can "delete", and then post a new one.
Clients following the delete request can choose how to display it in the UI.
In all other clients, it would be cool if it just looks like a quote tweet of the old note.
==
Benefit of quoting each of the edited versions - you can wee what engagement/comments were there with the specific previous versions of the note.
==
UX-wise, in terms of other users experience (who might have responded/boosted/quoted) your old note - I don't see any clean way how to allow edit without actually NOT hiding the previous versions.
post nsec to kill account
no