Q:所以密钥的保管与保存确实是一个问题，但并不是想象中那么严重和急迫解决的问题。而且从另一方面讲，其实它也帮助 Nostr 在快速的破圈，因为 Web 3 钱包其实还是有着“壁垒”存在，也阻挡了很多 Web 2 的用户。

那除了这个问题，还有哪些比较迫切的，摆在“台面”上的问题？

再就是随着用户的陆续涌入，整个网络的流量会变得非常大。这时候想象一个极端情况，如果大家为了保存自己所有的历史消息，把全部信息向每一个 Relay 发送一遍，当这个情况成为普遍，绝大部分的 Relay 上就会存储大量重复的信息，Client 在抓取信息的时候，也会将包含重复信息的 Relay 从头到尾扫描一遍，这个方案相对而言就非常低效。

在早先第一波用户快速增长的时候，有很多的开发者会有一种非常“崩溃”的情绪，他们会觉得很多方案并不奏效，这么多人进来了网络要瘫痪了怎么办？所以我觉得这些确实是在下一波用户增长之前，尽可能需要解决的问题。如果不解决，会给用户带来很多不好的用户体验，比如信息无法加载，客户端的渲染与加载缓慢之类的问题，很难留下更多的用户。

Q:是的，试想如果我是一个内容生产者，在 Nostr 的 Relay 上发布内容，在时间成本允许的情况下，如果操作还不复杂，我可能也会选择多 Relay 发送，这样确实就会存在重复信息导致整体运行与加载速度变慢的情况。

这个问题目前有两个主流解决方案，一个是在 Nostr 上加一层 Layer，相当于在整个 Nostr 协议外架一层Layer 2  ，上面只运行有限个节点，数量较整个 Relay 数量更少，每一个节点对它选择的 Relay 数据做缓存，客户端只和缓存节点沟通，这样会完善用户体验。目前有一个客户端实现了这个功能，上面的信息加载也非常流畅，但这个方式遭到了很多人反对，原因是我们好不容易做出了去中心化协议，最后却回到客户端只和少数或单一节点沟通，又回到了中心化的路线。

还有一个叫 Gossip model，因为最初实现这个模型的客户端叫 Gossip。它的运行方式是用户发布一条信息，信息上会写清楚，用户从哪个 Relay 上读取信息，向哪个 Relay 写信息。这样客户端在抓取全部信息的时候，它只会去关联节点抓取请求用户的读写信息，这样就会减少重复 Post 的情况。

Q:前面我们聊了关于公钥的隐私安全，也谈了 Relay 设置的利弊以及衍生问题的担忧。

接下来我们聊聊 Spam 的问题，这可能目前的热点话题了，您觉得为什么 Spam 问题在 Nostr 会这么突出？

首先是因为 Nostr 很新，目前有一些 Anti Spam 的办法，但大部分的措施核心都是关键词过滤，我觉得对于英文圈的用户来说，这可能是他们遇到过的最复杂情况，但对我们来说可能不一样，如果我发送一个火星文，关键词过滤就完全不起作用。

再一个就是目前绝大部分 Relay 是免费的，在初期大家可能觉得无所谓，可以免费把我的 Relay 拿来用，也不设置任何规则，全部的人都可以来读写，但这也导致 Spam 没有任何成本。账户的生成也非常容易，传统的账户可能需要和邮箱，手机号绑定，但在 Nostr，只要点击 Generate Key（生成密钥），就可以立刻获得一个新身份，因此批量生成 Spam 账号是完全可行的，而且非常的简单，也约等于 0 成本。

Q:其实我有一点没明白的是，为什么他们要生成大量的 Spam 账号呢？因为这个系统中也不存在某种代币激励或经济激励，这么做的目的是什么？就是为了发垃圾广告，钓鱼广告？

主要的目的是引流，此外也不只是 Spam 的问题，也还会有一些敏感信息的存在。

Q:虽然 Spam 问题在现阶段的 Nostr 中出现，但其实在其它领域也是个老问题了，那在已经成熟的生态或领域里，都有哪些方法解决 Spam 问题？

一种是使用深度学习技术，通过文字或是图像识别。另外一种是做用户行为的分析，在中心化系统里，Spam 账号的行为一定和普通用户的行为是有所不同的，比如它的发送频率可能会突然改变，某个账号已经半年没有任何行为了，但它突然变得特别活跃，通过诸如此类用户行为的分析，可以达到一种比较精准的防范 Spam 的功能。

Q:刚才我们聊到，现在所有的 Relay 节点都是免费的，那如果收费会不会是一种行之有效的方法？

并不是所有的 Relay 都免费，只是大多数的，现在已经存在收费的 Relay，收费 Relay 确实没有 Spam 问题。因为在 Spam 大量出现之前，收费 Relay 相对而言使用的人更少，直到突然有非常多中国大陆和中国香港的 IP 进入（因为很多 Spam 的服务器架设在香港）以后，大家才想到去寻找收费 Relay，所以在那一段时间收费 Relay 的用户订阅量有显著的增长。

Q:也就是说目前关于 Spam 的解法，收费作为一种小规模的尝试，起到了一定的效果。说起解法，接下来就要聊到 NIP（Nostr Implementation Possibilities，Nostr 功能实施可行性），目前 Nostr 上的 NIP 还是比较多的，也不断在更新，而您也是相关的中文编译者，我有两个问题：一是现在整体的 NIP 提案是什么状况，进展如何？二是这其中有没有您觉得比较有趣的，能针对 Spam 问题的一些措施？

最开始的时候，NIP 的标准是比较低的，只要有 1 到 2 个 Client 实现了协议，就会被 Merge（合并），现在要求会高一点，因为用户不断在增加，可能需要 3 到 5 个 Client，或 5 个以上实现某个 NIP，它才会被 Merge 到主分支。

之前有过两个协议和 Spam 有一些关系，一个算是主动，一个算是被动。主动的就是存在一个 sensitive content warning（敏感信息警告），如果用户发布了未成年人不适宜的内容，就会标注 Warning，这也算是一种比较良性的 Spam。另一个是叫 Report 的协议，也就是可以举报某个用户。我记得在上个月 Nostr 发生了一件事，有一个女孩子发了一张自拍，评论区就有人对她进行了侮辱，很多人就对评论点击了举报。

而之后一个绕不开的话题就是，用举报等方式剥夺他人发言权和 Nostr 所谓的自由是不是相悖的？审核一定会存在，但到底由谁来审核，我们有没有可能通过 Relay 把它区分开等等都是问题。当然也有很多人觉得，或许可以专门有一个 Spam Relay，比如全是暗网黑市信息的 Relay，一个都是黄色信息的 Relay 等等，因为 Nostr 的核心就是不会阻止你去做任何事。

Report 的 NIP 产生其实也很有意思，它最开始出现是因为 Damus 的创作者，基于 Apple 商店的要求，也就是上架之前必须要加一个 Report 的功能，直到最后演变成了一个 NIP。

Q:对的，当时 Damus 在 Apple 应用商店上架时还是挺波折的，说不定正是有这层关系在，所以需要对它增加一些底层机制。

是的，遇到了不少阻力也是因为很多在 Web 2 里执行起来非常简单的事，转移到 Nostr 的架构上，它反倒会变得更复杂。

Q:其实有关审查和举报的话题我觉得还是挺有意思的，就是去中心化这件事到底应不应该有边界，是不是有一个所谓的“底线”呢？您怎么看待这件事？

我觉得这可能是谁来做“筛选”的问题，也就是审核的权力到底谁该赋予，赋予谁，怎么赋予，为什么赋予。

Q:但前提是一定要有“筛选”？

是的，我认为“筛选”是必要的。尤其是考虑到可以