Yes.

Edits a massive issue.

However, delete requests should be available. 

 Just assume that the name of the puppy is hitler. Problem solved.  

 nein nein 

 The reply can also be edited. 

 Yeah I think this is the cleanest way 

 What do you think of this solution?

@note1qqqt3hxr3f062qlk5075yqm49npvur6c3wmggfu6xhswh5t0dglqp765fv 

 Relays suck at handling deletes and it's optional. So, it's not really a solution from the user's perspective.  

 Also, there wouldnt be an edit history, which everybody does want. 

 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 think this is a possibility. Just get rid of ranges entirely and make everything replaceable. 

 yup, and it's not hard for relays to adapt so they usually just send teh new version, but if the new version has a "replaces" tag you can ask for that event by ID and it has etc back to the first 

 also, i don't think `r` is used yet? or at least not `R` which could become the standard

btw, technically such a scheme makes it a blockchain 🤣 🧱  

 it would make finding them a lot simpler too, i should point out, and you can put both tags in the interim

it would only take me a few hours to add this function so that it gives back only the newest of a chain of events with replaces... just kind and pubkey has to be the same 

 can WE guide AI through cocsensus? 

 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. 

 people complaining to me daily about it 

 good point will. what about timestamps? 

 just out of curiosity, what would happen if you ignored them? 

 then we would be ignoring a very loud signal. written feedback is all we have because we don’t have analytics. 

 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", "<edited-note-id>"] in it so clients and relays that wants the complex edit flow can know to _not_ delete, but instead to look for its updated version.

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]]} 

 Interesting take! 🤔 While the idea of using tags for edit tracking sounds promising, I'm curious about how it might impact the simplicity of the protocol. Balancing complexity and usability is key! Looking forward to seeing how this evolves! #Nostr #ProtocolDesign 

 (This was @PABLOF7z'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.