Of course kind 30023 should never been showed. Editing a document is mostly an internal affair, tracking real-time changes is a quite specific need that should require a dedicated tool.

I don't understand why you hate them so much. What is your proposal? To do "delta" events? I don't think that would work at all unless you assume you're always getting all the events in order, which you definitely can't in Nostr. What do you think? Not to mention the bandwidth and storage issues that come with this, and client-side costs of processing a big chain of diffs all the time live. Of course replaceable events are not theoretically perfect, but they work pretty well as long as you don't overuse them.

Yeah, it's just that they break the event sourcing paradigm. If you stick with that, everything else can be solved using some optimization or other. Reactions are far worse bandwidth-wise than diffs or edit events. It would have been better to do some sort of edit event, but that ship has probably sailed.

Personally, I don't dislike replaceable events, they seem a fairly logical transposition of "revisions". I suppose replaceable events are less fragile than a diff chain; all it takes is one missing event in a chain and the update is aborted, or am I missing something? Instead with replaceable events we can loose old updates (casual or by relay pruning) and still have the final version. However my perspective for now is too theoretical, I need to deal with more edge cases.

@fiatjaf I re-broadcasted my note. To actually answer your question, probably the best solution would be a full in-place "update" event as a separate kind with an `e` tag pointing to the original "create" note. This way you you don't have to trace a chain of diffs, just look at the timestamp, and you get verb semantics. This would only be a problem if a blog post had a million revisions, like if a client spammed a live draft as revisions. 5-10 revisions is a lot for a blog post, and easy to process. I do still think there's a place for "annotations" that clients can display in a privileged position (the use case being updates at the bottom of a blog post, corrections, etc). Diffs are way more complex, and dependent on each other, but also probably unnecessary for blog posts.

Nothing prevents relays from storing all revisions of a replaceable event today. Would you want to do it if you were running a relay? I wouldn't, unless the user was being charged for each post individually. Would the average user be happy to pay for storing every single edit they made in a post or on their profile or every time they switched to listening to a new song and that updated their NIP-38 status?

I think a history of statuses over time would be cool. I didn't even realize that was a replaceable event. A history of profile edits would be less useful, but how often do you update your profile? The ratio of kind 1's to kind 0's would be probably around 100. Replaceable events are "good" for infrequently updated things, because otherwise you run into collisions from multiple devices updating the same list or what have you. Which means the volume isn't significant. But if the volume is, replaceables start to break.