从 Fediverse 垃圾内容攻击到 Nostr 事件传递与存储

从 Fediverse 垃圾内容攻击到 Nostr 事件传递与存储 Fediverse 最近遭遇了一轮大规模的垃圾信息攻击, 身边的朋友大多都收到了影响, 管理员们也在积极互助传递从服务器抗击和清理垃圾内容的方案.

这也不由得提到 Nostr 中的同样存在的大规模垃圾内容问题. 在 Nostr 客户端刚上线的时候, 主流的免费公共中继提供的全球时间线几乎全都是垃圾內容, 而且大部分还是中文的. 而后的几个月, 热度褪去, 似乎 Nostr 对操控垃圾账户的人失去了吸引力? 在服务端这边, 中继器的管理员面对已经存在的垃圾内容也只能通过手动或脚本的方式操作数据库删除, 甚至部分免费的中继器会有定期清空数据库的习惯, 或者针对特定类型的事件进行清理. 随后, 付费中继开始集中涌现出来, 也是一种基于金钱的工作量证明中继准入的方式, 当然目前所有的付费中继也没有任何一个承诺用户数据持久化, 即使是头部的 nostr.wine 准入门槛高达 $9.99 也没有, 甚至推出过专门针对持久化存档事件提供的服务(现在似乎下线了).

从中继管理员直接操纵数据库清理垃圾内容似乎是最高效的, 但是这也暴露出 Nostr 依旧受制于传统基础设施不「抗审查」, 中继管理员即使无法签署 kind-5 事件来删除我们的事件, 只需要让它们数据库里的行列消失就已经足够了. 中继查找不到事件, 自然就做到了审查, 其中也包括了公钥对应的最基础的用户资料, 如果公钥不存在任何关联事件, 那么这对密钥就等于没有任何价值. 社区开始反思目前的状况, Nostr 中 T 代表传输, 没有任何一个关键字代表着存储, 也就是中继并不应该承担保存事件数据实体的用途, 而是仅传输1, 中继选择保存事件到数据库那是受限于空间和时间做出的妥协. NIPs 也没有规范中继软件如何存储用户事件在服务器中. 但是现在没有任何一个客户端支持在事件被广播出去之前将这串 JSON 保存在本地以供日后不时之需, 同时也养成了错误的用户习惯, 用户默认了中继就是保存 Nostr 网络中一切的地方, 发送完事件后就再也不管了. 这可能确实需要一些改变, 结合上文的垃圾信息攻击问题, 到最后真正保存下来的事件恐怕只有私人中继和用户本地存档中的事件.