I think edits can be facilitated entirely within the client. When people post a note or a replay, the client could delay broadcasting for a period of time (60-90sec), during which time the note is essentially a draft that can be edited. Once the time limit is up, the posted note including any potential edits are broadcast. This removes any necessary work within the protocol, or programming of the relays as it's all done within the client. And each client would be able to choose whether to support the feature, while edits would automatically be seen network wide.
Discussion
I would agree if it wasn't for the issue that many edits are made after 90 seconds. Usually when the user comes back to read it again and sees all the typos and grammar issues.
It's not a wide open solution, but in my experience people notice typos, which is the type of edit that should be facilitated, right after they post the note. And if users knew they had a 90sec buffer to make those minor changes, I think they'd be more likely to review their note after posting. I think such a solution would be a lot better than what we have even if it's not perfect.
Other than Vitor’s point below, this is a pretty smart approach 🤝
It wouldn't require that every client and relay dev commit to a unified solution. Each client could for themselves whether of not to implement it. And to make it more useful, users could be able to modify the delay time. This would have the dual purpose of personalized config, and raising awareness of the feature.
Ooh. I dig.
I love that idea of the (optional) user-determined time delay, before a note is released.
Kind of like how more email clients have started offering a brief “unsend” period for when you second-guess that snarky reply to your boss 😂
i like this approach a lot