Oddbean

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

I'm wondering how the UI/UX for this would be, since basically it's a new address with each new event in the edit chain. I'm thinking a button would appear ('view latest version' or something) if the client detects that the user isn't viewing the latest version of the post, and a 'view all versions' button in sub-menu, showing all events in the chain. In terms of seeing such posts in a general feed (or viewing a profile), the client should auto-swap to the latest version (perhaps there'd be a small visual indication to show 'checking for edits') and hide the previous version (which would be visible in the 'view all versions' page.