Nostr一直称自己为一个真正抗监管的现有中心化社交平台的替代品，其应用Damus成了最近Web3界的爆款。本文基于Nostr的Github对Nostr协议进行了大致的梳理，分析其独特的技术原理和核心问题。
一、Nosttr，一个抗监管的社交网络协议
Nostr为去中心化的社交网络协议，目标是建立一个真正抗监管的全球社交网络。它不依赖于任何受信任的中央服务器，因此网络具有相当的弹性；它基于加密密钥和签名，因此是防篡改的；与传统的去中心化思路不同，它不依赖于P2P技术，因此更为易于运行。
每个用户都运行一个Nostr客户端，可以是Web客户端、应用客户端等。用户要发布某些内容，可以用其密钥对内容签名并将其发送到多个中继（由其他人或者用户自己托管的服务器）。要从其他用户处获得发布更新，用户可以通过客户端询问多个中继，他们是否了解这些人。任何人都可以运行中继，中继的功能十分简单，除了接受某些用户的帖子并转发给其他客户端之外，它什么都不做。中继不需要被完全信任，内容的签名在客户端进行验证。
二、现有方案的问题和不足
（一）一些国外主流的社交平台的问题
1.平台具有广告;
2.平台具有令人成瘾的推荐算法;
3.平台会封禁用户;
4.平台会以限流等方式秘密的屏蔽用户;
5.平台上有很多垃圾信息。
（二）Mastodon等类似协议和应用的问题
1.用户身份依附于第三方控制的域名上；
2.服务器所有者可以像中心化社交平台一样禁止用户；服务器所有者也可以阻止其他服务器；
3.服务器之间的数据迁移只有在服务器协作的情况下才能完成，且会导致追随者的丢失；
4.运行服务器没有明确的动机，因此它们往往由爱好者和那些希望将自己的名字附加到一个很酷的域的人运行。然后，用户受制于服务器控制者的专制，难以迁移数据。由于服务器往往是业余爱好者运行的，所以它们经常会在一段时间后被放弃。
如果来自每台服务器的更新都必须推送并保存到大量其他服务器，这对服务器的压力是巨大的，需要对服务器配置有很高的要求。
对于视频共享的具体示例，开发者识到完全不可能像文本注释那样在服务器之间传输视频，因此他们决定仅从发布视频的单个实例托管视频，即类似于Nostr的解决方案。
（三）SSB应用（SecureScuttlebutt）的问题
Nostr开发者认为SSB的问题较少，是一个很棒的项目，曾计划以该项目为基础。
协议太过复杂，难以被认为是一个开源协议。由于协议发展历程的原因，协议中有些令人难以理解的严苛之处，譬如签署一个必须严格遵守ECMA-262第6版规则的JSON字符串；
SSB坚持从单个用户处获得连续的更新，这对Nostr来说是不必要的，而且会导致数据的膨胀和网络的僵化——每个服务器/用户都需要存储所有用户内容组成的区块链以确保新的是有效的。SSB不像Nostr那样简单，因为它主要是以P2P同步为基础而设计的，pubs模式是之后才想到的
三、Nostr协议如何运作？
有两个基本组件：clients和relays。每个用户运行一个客户端，任何人都可以运行中继。每个用户都由公钥标识，每个发布内容都会经过用户私钥签名，客户端会验证这些签名。
客户端从他们选择的中继获取数据并将数据发布到他们选择的其他中继。中继不与另一个中继通信，仅直接与用户通信。例如，要「关注」某人，用户只需令他们的客户端查询它知道的中继以获取来自该公钥发布的内容。
在启动时，客户端从它知道的所有中继中查询它所关注的所有用户的数据，然后按时间顺序向用户显示该数据。
一个发布可以包含任何类型的结构化数据，但最常用的数据将写入标准，以便所有客户端和中继可以无缝地处理它们。
四、Nostr如何解决上述网络无法解决的问题
（一）抗监管：用户被禁止发布内容或是服务器被关闭
中继可以阻止用户内容发布，但这对用户没有影响，因为用户仍然可以发布到其他中继。由于用户是通过公钥识别的，因此当他们被禁止时，他们不会失去他们的身份标识和他们的追随者基础。不需要用户手动输入新的中继地址（虽然这也应该被支持），每当用户关注的人发布中继服务器推荐信息时，客户端应该自动将其添加到它将查询的中继列表中。
如果有人正在使用中继发布他们的数据但想迁移到另一个中继，他们可以发布一个服务器推荐到之前的中继然后去，以便他的追随者可以找到他。
如果某人被多个中继禁止，以至于他们无法广播他们的中继服务器推荐，他们仍然可以通过其他方式让一些密友知道他们现在正在哪个中继发布内容。然后，这些密友可以发布有关新服务器的推荐，慢慢地，被禁用户的老粉丝群将开始从新中继重新找到该类用户的发布。
（二）垃圾信息
如果垃圾信息对中继运行构成压力，用户可能需要支付发布费用或一些其他形式的身份验证，例如电子邮件地址或电话，并将这些在内部与公钥相关联，然后发布到该中继。如果中继被用作垃圾信息服务器，它很容易被客户端取消连接，客户端可以继续从其他中继获取更新。
（三）数据存储
为了让网络保持健康，不需要数百个活跃的中继。事实上，考虑到在现有中继开始出现异常时可以轻松创建新中继并通过网络传播这一事实，它只需少数几个就可以正常工作。因此，所需的数据存储量通常比Mastodon或类似软件要少。或者考虑一个不同的结构：其中存在数百个由业余爱好者运行的小型中继，每个中继从一小群用户中获得更新。该体系结构也可以扩展：数据从用户发送到单个服务器，然后从该服务器直接发送到将使用该数据的用户。它不必由其他任何中继存储。在这种情况下，任何一台服务器处理来自其他服务器的更新都不是很大的负担，拥有非专业服务器也不是问题。
（四）跨中继器的事件信息传递
事件是中继和客户端传递信息的基本格式，所有事件都以特定定义的方式构建。包括创建者的公钥、创建时间戳、类型（或规范中的种类）、内容有效负载和事件创建者的签名。另外，还可以有引用其他事件或用户的标签，并且有一个ID值，该值是除创建者签名之外的所有内容的哈希值（类似于比特币交易的TXID）。事件也可以包含标签，通过标签中对其他中继地址的引用，一个用户在一个中继服务器上发布他们的内容，可以与另一个用户在不同的中继服务器上发布的内容进行互动和引用。
五、一些核心的问题
（一）中继的突然关闭
由于用户的数据存储在中继之中，用户之间的通讯、内容的传递基于两者连接同一个中继器。虽然说可以通过前期消息发布者推荐的中继提前构建备用的中继链接，但是这种前期准备并不是必须的，且备用中继也存在关停的风险。
（二）如何连接目标用户所在的中继
整个Nostr协议依赖于某个地方的人运行一个中继服务器。没有「Nostr网络」，中继之间互不通信，只有中继和连接到中继的客户端。用户如何找到中继？如果用户没有连接到其他人连接的相同中继会怎样？这是每个用户都关心的事。事实上在这种情况下，用户将无法与目标用户交流。
虽然用户可以在事件中留下一些服务器推荐，作为找到中继服务器的线索，但是中继只能通过客户端间接广播信息，这种线索的找寻依旧充满着不确定性。
（三）基于发布者的信任机制
同时，Nostr放弃了对中继内信息的去中心化验证和审查，这便意味着信任机制是给予内容发布者的而不是基于整个网络，内容发布者可以通过自生的密钥对内容进行修改后重新签名。虽然在客户端和中继上可以施加验证措施，但是由于两者都不是必要唯一的，用户可以随时更改客户端和中继，因此信息难以验证是否被篡改。
写在最后
在很多Nostr的群聊中潜水，发现现阶段很多用户只关心应用层面的表象，而不关心协议层中的实质，将这个新出现的协议以区块链的去中心化解决方案去理解。实质上两者在信任解决机制上存在相当大的差异，Nostr协议中还有相当多的问题尚待解决。只有当底层的协议解决完成，基于协议的应用才能变的好用，可用，才能真正的让用户心甘情愿的抛弃掉中心化的社交平台。
（声明：请读者严格遵守所在地法律法规，本文不代表任何投资建议）
