一文了解 nostr ：马斯克怕到封杀的去中心化社交协议

2023-02-02 04:02

本文转载自：DeFi之道

撰文：git-sgmoore 和 fiatjaf （nostr）

编译：DeFi 之道

“硅兔君荐语

被Damus刷屏了吗？被称为“推特杀手”，至少三次被大科技公司拒绝上架的去中心化网络社交平台，到底有什么魔力？

近期一个名为 nostr 的去中心化社交协议获得了比特币社区的追捧，这引来了 Twitter 现任 CEO Elon Musk 争议性的封杀政策，同时让 Twitter 前任 CEO Jack Dorsey 自掏 14 BTC 为其提供资助。

Twitter 的最新禁止政策

根据介绍，nostr 是一个最简化的协议，它能够一劳永逸地创建一个抗审查的全球“社交”网络。

nostr 不依赖于任何受信中央服务器，其基于密码学密钥和签名，并且不依赖于 P2P 技术，它也不会发行 token。

那它的运作原理是怎样的呢？简单来说：每个人都运行一个客户端，这可以是本机客户端、Web 客户端等。要发布某些内容（比如一个帖子），你要用你的密钥对其签名，并将其发送到多个中继器（由其他人或你自己托管的服务器）。要从其他人那里获得更新，你可以询问多个中继器是否了解这些其他人。任何人都可以运行中继器，这是非常简单的，除了接受某些人的帖子并转发给其他人之外，它什么都不做。我们也不需要信任中继器，签名是在客户端进行验证的。

1、如何开始使用 Nostr

2、Nostr 客户端功能比较

3、基于 Nostr 的项目列表

01 其他解决方案存在的问题

1、Twitter 的问题

Twitter 有广告；
Twitter 使用奇怪的技巧让你上瘾；
Twitter 不会显示你关注的人的真实历史动态；
Twitter 会禁止某些人的账户；
Twitter 会使用影子禁令（Shadowbans）.
Twitter 有很多垃圾信息；

2、Mastodon 和类似应用的问题

用户身份附加在第三方控制的域名上；
服务器所有者可以像 Twitter 一样禁止你，服务器所有者也可以阻止其他服务器；
服务器之间的迁移是事后才考虑的，只有在服务器协作的情况下才能完成。它在对抗环境中不起作用（所有追随者都会丢失）；
运行服务器没有明确的动机，因此它们往往由爱好者以及希望将自己的名字附加到一个很酷的域名上的人来运行的。然后，用户受制于一个人的专制，这往往比 Twitter 这样的大公司还要糟糕，他们无法迁移出去;
由于服务器往往是业余的，它们经常在一段时间后被抛弃——这实际上等同于禁止所有人;
如果每台服务器的更新都必须痛苦地推送(和保存!)到大量其他服务器，那么拥有大量服务器就没有意义了；这一点由于服务器数量庞大而加剧，因此更多的数据必须更频繁地传递到更多的地方;
对于视频共享的具体示例，ActivityPub 爱好者意识到完全不可能像文本注释那样在服务器之间传输视频；

3、SSB（Secure Scuttlebutt）的问题

它没有太多问题，我认为这很棒。事实上，我打算以此为基础，但是它的协议太复杂了，因为它根本就没有被认为是一个开放的协议。它只是用 JavaScript 编写的，可能是一种快速解决特定问题的方法，因此它有奇怪和不必要的怪癖，比如签署一个 JSON 字符串，其必须严格遵守 ECMA-262 第 6 版规则;
它坚持从单个用户那获得一连串的更新，这对我来说是不必要的，而且会增加内容的臃肿和僵化程度——每个服务器/用户都需要存储所有的帖子链，以确保新的帖子是有效的。为什么要这么做 ?(也许他们有很好的理由);
它不像 Nostr 那样简单，因为它主要是为 P2P 同步而设计的；
不过，可能值得考虑使用 SSB 而不是这种自定义协议，并仅使其适应客户端中继服务器模型，因为重用标准总是比尝试让人们使用新标准更好。

4、其他要求运行服务器方案的问题

他们要求每个人都运行自己的服务器；
有时人们仍然会在这些方面受到审查，因为域名可能会受到审查；

02 Nostr 的运行原理

Nostr 有两个组件：客户端和中继器。每个用户运行一个客户端，任何人都可以运行中继器。
每个用户都由公钥标识，每个帖子都有签名，每个客户端都会验证这些签名。
客户端从他们选择的中继器获取数据，并将数据发布到他们选择的其他中继器。中继器不与另一个中继器通信，仅直接与用户通信。
例如，要“关注”某人，用户只需指示他们的客户端查询它知道的中继器，以获取来自该公钥的帖子。
在启动时，客户端从它知道的所有中继器中查询它所关注的所有用户的数据（例如，从最近一天开始的所有更新），然后按时间顺序向用户显示该数据。
“帖子”可以包含任何类型的结构化数据，但最常用的数据将进入标准，以便所有客户端和中继器可以无缝地处理它们。

03 Nostr 如何解决其他方案无法解决的问题？

问题1：用户被禁止，服务器被关闭

中继器可以阻止用户在它那里发布任何内容，但这对用户来说没有影响，因为他们仍然可以将内容发布到其他中继器。由于用户是通过公钥识别的，因此当他们被禁止时，他们不会失去他们的身份以及粉丝基础。

不需要用户手动输入新的中继器地址（虽然这也应该被支持），每当你关注的人发布服务器推荐时，客户端应该自动将其添加到它将查询的中继器列表中。

如果有人正在使用一个中继器来发布他们的数据，但想要迁移到另一个中继器，他们可以向之前的中继器发布一个服务器推荐，然后离开;

如果有人被很多中继器禁止，以至于他们无法广播他们的服务器推荐，他们仍然可以通过其他方式让一些亲密的朋友知道他们现在正在发布到哪个中继器。然后，这些亲密的朋友可以向新服务器发布服务器推荐，慢慢地，被禁用户的旧粉丝群将开始从新的中继器中再次找到他们的帖子。

当中继器停止工作时，上述所有规定也都是有效的。

问题2: 抗审查

每个用户都可以将他们的内容更新发布到任意数量的中继器。

中继器可以向用户收取费用（目前费用的协商不在协议范围内）以在那里发布，这确保了抗审查性。

问题3:垃圾信息

如果垃圾信息是中继器要关注的一个问题，它可以要求为发布付费或其他形式的身份验证(如电子邮件地址或电话)，并将这些在内部与公钥相关联，然后将其发布到该中继器或使用其他反垃圾信息技术（如 hashcash 或验证码）。如果一个中继器被用作垃圾信息载体，它很容易被客户端取消，客户端可以继续从其他中继器获取更新。

问题4: 数据存储

为了让网络保持健康，不需要数百个活跃的中继器。事实上，它只需要少数几个就可以很好地工作，因为在现有中继器开始出错的情况下，可以很容易地创建新的中继器，并在网络中传播。因此，所需的数据存储量在一般情况下，要比 Mastodon 或类似软件要少。

或者考虑一个不同的结果：其中存在数百个由业余爱好者运行的利基中继器，每个负责一小群用户的更新中继工作。这种架构也可以扩展：数据从用户发送到单个服务器，然后从该服务器直接发送到将使用该数据的用户。它不必由其他任何人存储。在这种情况下，对于任何单个服务器来说，处理来自其他服务器的更新都不是很大的负担，拥有业余服务器也不是问题。