+1 to this version

Using a regular event as anchor does solves the parameterized replaceable event problem of making the .created_at mean "updated at" which breaks the since/until filtering expectations.

This one is also backwards-compatible.

This one is also backwards-compatible.

I don't know. Clients that don't support edits will display the wrong version. So, I wouldn't call it backward compatible.

The other PRs do it without changing kind 1. Those posts won't show in current clients, but no other new kind would as well. That's just the expected behavior at this point.

But this one is the easiest to code.

The other PRs downside is that they split the microblogging scene. Old kind:1 clients will appear as broken cause they would miss more and more notes as time passes and people start using clients that have note editing feature.

As usual, I object to replaceables on the grounds that they destroy information. I would prefer non-replaceable events so that it is possible to find out which version of an event someone replied to. Also NACK kind 1s are beautiful as they are. "Author comments" would be a better approach, because they would not need to be fetched by old clients (since the original content is immutable), but authors could still make corrections.

I object to replaceables on the grounds that they destroy information.

That's an implementation detail, though. { kinds: [0], authors: [alex] } could easily return multiple versions on the relay side. However, { kinds: [0] } should return only the latest profile for each user.

could easily return multiple versions on the relay side.

That's a hack to get around the awful semantics of replaceables. If we want something like this we should introduce "projections" as a first-class feature (which I also object to if they're going to be added to relays, but would be fine to add via DVMs or other services).

Ok, new PR #1090 does it without replaceables.

Closing in favor of #1090