1. we can't really edite something on nostr since we obtain id from hash of content.
2. why we should not use a replaceable kind instead?

or something like an addressable event with a random unique d. then we can try query this editable thing using d tag value to get the latest edited version. clients can show it in a same place/order as well then.

@kehiy replaceable/addressable kind is artificially limited to a kind number range (i.e. can't be simultaneously addressable and ephemeral -edit: bad example).

Also, if, for example, you want to make an event unique by its e and p tags, while still being searchable by these tags, you must duplicate the values. See the difference:

Currently:

{
  tags: [
    ["d", "<event-id>:<pubkey>"],
    ["e", "<event-id>"],
    ["p", "<pubkey>"],
  ]
}

This NIP:

{
  tags: [
    ["dd", "ep"],
    ["e", "<event-id>"],
    ["p", "<pubkey>"],
  ]
}

Currently:

{
  tags: [
    ["d", "<event-id>:<pubkey>"],
    ["e", "<event-id>"],
    ["p", "<pubkey>"],
  ]
}

This NIP:

{
  tags: [
    ["dd", "ep"],
    ["e", "<event-id>"],
    ["p", "<pubkey>"],
  ]
}

This seems like a tiny improvement for the amount of extra complexity custom-parsing dd tags on relays and clients in this NIP.

@vitorpamplona it is not only saving space but it could be used for any event kind. It is basically #236, that wanted to make all event kinds replaceable/addressable. I just didn't use the d tag cause its spec is already ossified and also I took the opportunity to do that format improvement you quoted.

Like you said here, something like this PR doesn't need relay buy-in and "Event kind ranges can be deprecated.". edit: In my view, "deprecate" in the sense of possibly falling into disuse.