目前 Nostr 允许内容互相替换的只有 kind:30023 (参数化可替换事件), 如果再引入编辑功能可能会继续影响事件的传递和检索效率(服务端一侧).
quotingFWIW, I think deletions on Nostr are a "meh" idea and edits are a bad idea. Consider the following:
nevent1q…asxv
- It's an additional layer of complexity. Nostr should arguably be simpler and it's already more complex in some ways centralized platforms are not.
- Different relays will disagree on whether to accept the edit or the delete event, so the original note may stay available. It may also become apparently unavailable and then available again in the future. Someone could send the old version to relays you don't use.
- Unlike some specific features like articles, zaps and whatever one can think of, it only makes sense if consistently implemented, but that's something we can only assume to be true of NIP-01.
- It makes retrieving a note less efficient. You now need to wait a response from all relays, just in case one of them has a deletion or a modification the first one to reply doesn't have.
- There is value in having modifications, but there is also value in having platforms that don't allow modifications, IMO, where an ID truly identifies a specific piece of text and nothing else. Now that Twitter allows modifications, Nostr can use the fact that it doesn't to diversify itself so as to convince users to use both (otherwise the network effect plays against Nostr).
On centralized platforms which allow modifications, users sometimes write a post with the plan of modifying it later. On Nostr that would be a bad pattern, however and I think the modification features can lead to bad usage of Nostr and, therefore, a bad user experience.
Ultimately it will prevail if clients and relays implement it and fail otherwise, but I'm not in favor of it.