# 删还是不删，这是个问题。较受争议的【 #NIP-09 : Event Deletion】🐰ᥬ[🐶]᭄🌿

1～不强制完全删除

协议末尾说了不强制各实现端或Relays支持，另外还说『Clients SHOULD hide or otherwise indicate a deletion status for referenced events.』 即不用完全删除，可以隐藏或标记一下等其它方式实现。例如可参考微博的编辑历史可多个叠加在一起，查看历史编辑记录。可删删了叠加新的覆盖，即意味着 #Note 可编辑。

2～想要撤回的原因

一会儿我可以发起个⚡️投票 #NIP69 调查下，我猜很大一部分是因笔误，错别字，或因格式错误，图片未能按预期展示，这些可理解，且往往刚发完就发现了。因此规定短时间如十分钟内可撤回是可以的。

建议1：写完发出来内容前，自己再从头细读一遍再发，而不是写完立刻发布，这样能避免大多笔误和错别字。

建议2：重要且长内容尤其是包含markdown的长文，复制下内容可先在小号发出来，看看格式与图片等都可以，符合预期，再到大号上发布。

3～不应撤回的情况

有些人乱预测，后来事实将其打脸，于是就删除屏蔽当时的预测。更有“聪明”的，同时两个相反的预测，例如发个明天张，再发个明天跌。第二天涨了就把跌哪条删除，反之删另外一个。打造成了每次都精准预测的预测大神形象。

另外『君子一言，驷马难追』，若支持删除，有可能增加造成说过的话不算数的情况。另外如错别字，笔误等，在不可撤销压力下，能帮用户培养成发送前读一遍，三思而后行，再后点按钮的良好习惯。

https://github.com/nostr-protocol/nips/blob/master/09.md

或者汉化 https://github.com/cndx/nostr/blob/main/nip09.md

大家怎么看，支持可删除还是不删？

lightning:cndx@nostrurl.com 🐇ᥬ[🐕]᭄🌿