It will impose huge overhead on all clients and kill Nostr.
Discussion
Do you consider replaceable events an overhead?
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
Event Twitter has a lot of trouble with editable posts, sometimes you are reading a post and it has a message saying "there is a new version", and then you click on that and it doesn't exist anymore or other shenanigans. I don't know how it's implemented internally, but I imagine it wouldn't be too different than this, except for the fact that they have a single codebase.
In Nostr it would either be unusable chaos or everybody would just resort to using the same client.
Replaceable events suck. Why use them on WikiNostr? Edit history is important.
nostr:note1kzzdmyahw78ujxfhfz05nsxfwpjjwvmu078xl5v8h05ewkau568s4vf2ne
AGREE
relays wont use it and people will stop using amethyst
