This is my main concern about edits on nostr, do people see the same concern or am I being overly cautious? Lots of ux issues. We would have to include metadata in the reply to even know which note is actually being replied to. This is pretty important in the example below. Many clients who don’t implement it may find replies confusing. I dunno… 
Discussion
Just assume that the name of the puppy is hitler. Problem solved.
The reply can also be edited.
Signal has replies and edit, Signal copies the quoted version so exactly the Austrian paintor thing doesn't happen
I agree, but I also think that nostr has adopted mutable state, for better or worse. I'm more concerned now about the complexity that this introduces to nostr's most important event kind. It's one thing for blog posts to support edit, which forces complexity onto only long-form clients, it's another thing to force everyone to support it.
Definitely icky, but users have needs 🥲
i think we just need to put textnote and article kinds into the "replaceable" basket with a tag `["replaces","eventid"]`
specifically, if a kind 1 or 30023
hold on, articles are already in the replaceable number range
so, already kind 0 is replaceable, so is kind 3 (follows), it's just a matter of a tag i think? maybe even just use `d` like the rest?
I'd say you are always replying to the message you replied to.
If OP changes their post, your reply disappears.
If someone finds your reply, OPs old post is shown above it with a message "this has since been edited".
Clients can show out of date replies as translucent or faded so readers know it is not a direct relationship and can dig further if they want.
At the very least, an edit ought to indicate that it is in fact an edit - even if the original is obscured.
... doing so ought to be sufficient to alert the reader to the potential of an outdated reply.
When did the no edit/no delete feature become a bug.
Does an edit not get a new note ID with some kind of link to the original? Replies should be to the version that the user saw and replied to.
The current spec doesn’t have that. Thats what I suggested
edited posts often gave me issues on twitter, like a link to an edited post would not show anything except a button to "refresh"
I still think sending a kind:5 followed by a new kind:1 with a reference to the previous version is the way to go. Clients that want can group replies to both posts together using some complex magic, but others can safely ignore anything that was deleted and just use the latest version and be happy about it.
Handling deletes properly is a complexity that we arguably shouldn't have introduced, but now that we have that we can easily build on top of it.
Maybe the kind:5 has a new tag ["edit", "
So the sequence would be like:
- {kind: 1, content: 'ehllo', id: zzzzzz}
- {kind: 1, content: 'hello', tags: [[r, zzzzzz]], id: ffffff}
- {kind: 5, tags: [[e, zzzzzz], [edit, ffffff]]}
(This was nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft's idea, by the way.)
You are certainly NOT being overly cautious; this situation does and will happen plenty. I've seen it happen elsewhere plenty of times.
Frankly, I hate the idea of editing posts for this reason primarily. Why waste your valuable time RN trying to fix this edit "problem" when there are far bigger fish to fry?
Mainstream social media seem do do fine mostly ignoring this, while marking modified comments as such and, optionally, showing all replies.
Edits are still a shitty idea on Nostr because they require fetching more than just the note ID and waiting after receiving the first response, increasing complexity and latency.