nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 , as you have it defined, is this UX flow an option for nostr:npub12vkcxr0luzwp8e673v29eqjhrr7p9vqq8asav85swaepclllj09sylpugg and nostr:npub16c0nh3dnadzqpm76uctf5hqhe2lny344zsmpm6feee9p5rdxaa9q586nvr if they used NIP37 to accommodate simple and immediate typo repair? I didn't put a countdown for edit availability, but that could be provided in the UI to inform the user that there's a sense of urgency to fix the typo before engagements causes the edit to be undesirable.

nostr:note1qqqvv5cxy2j977zsvsxga8fqxnnnfgsz84hu6ccljdjmnusa942svk9a6d

Reply to this note

Please Login to reply.

Discussion

Yes, but let me just say that many other edit NIP proposals also share the name "nip37" so we might be confusing some readers.

I guess instead of the warning text talking about NIP-37 the popup confirmation could say something like: "This may cause existing comments and reactions to this note to disappear in some clients. Read more."

I am not sure if I like the tweaked-delete-and-replace flow more or if I prefer the annotations-with-benefits spec for small typo fixes (this one: https://github.com/nostr-protocol/nips/issues/1569#issuecomment-2462978430). The second would have to enforce some limits to the amount of characters replaced in order to be decent.

I enjoyed the back and forth in the linked discussion. I tend to take this perspective since we cannot guess all current use cases or predict all future client needs:

- Protocol allows key flexible functionality in a scalable framework.

- Clients provide full or limited access to functionality based on their use case goals.

Honing my placeholder text makes sense. Whatever goes there that will manage the behavior expectation for the user, and let even a rookie know how the network will react to their action. I like that the link out to more info is a great opportunity to help people coming from centralized systems understand how a Nostr wild west client on relays will behave with their usage.