比特币开发者解读Nostr如何构建去中心化社交网络

1、Nostr基本介绍

Nostr是一个非常轻量级的开放协议，它“有望”（据其项目文档描述）成为去中心化的社交媒体平台。

该协议的基础是一个WebSocket服务器（称为nostr中继器），它处理和存储一个名为Event的简单数据结构。如下图所示：

event（事件）总能获签（使用Schnorr签名），它们包含有语义意义的结构化数据。在BIP340中定义的Schnorr类型XOnlyPubkey（目前与Bitcoin Taproot一起使用）作为“身份”（identities）应用于整个协议。

nostr客户端是一个可以与nostr中继器通信的应用程序，可以使用Subscription Filter（订阅过滤器）订阅任何事件集。过滤器可提供客户端感兴趣的所有nostr事件集。

客户端不需要注册或创建帐户。客户端用它们的pubkey进行身份认证。每当客户端与中继器连接时，它都会提交其订阅过滤器，只要它们处于连接状态，中继器会将“感兴趣的事件”传输给客户端。

中继器可以缓存客户端订阅，但却不必须这样做。客户端应该在“客户这端”处理所有事务，而中继器则可以像块迟钝的石头。

客户端之间互不通信。但是中继器可以。这允许中继器为客户端获取它所缺少的数据。客户端可以订阅与之相联的中继器之外的事件。

乍一看，Nostr协议似乎没有什么用（为什么不直接签署并dump原始JSON，让客户端来解决呢？），但深入研究就会发现，“dumb-server, smart client”（傻瓜式服务器，聪明的客户端）模型有某些巨大的工程优势，特别是在去中心化的协议设计中。

本文概述了这些傻瓜式服务器、聪明的客户端，以及比特币网络、端到端加密是如何结合在一起解决“去中心化社交网络”（DSN）问题的。

2、问题概述

如果过去的两年你不是与世隔绝的话，想必你已对目前市场上出现的“Twitter替代品”的紧急激烈的呼声有所耳闻。社交媒体平台不会与用户动机背道而驰。

这种需求催生了像Gab和Mastodon这样的社交媒体替代平台。前Twitter CEOJack曾发表的声明已经暗示，这将是下一个需要解决的重大问题。免责声明：我并不是说这是一个容易解决的问题，我也不认为Nostr能解决所有问题。但它至少“有望”解决问题。

创建去中心化媒体平台的核心问题不在于技术，而在于社交。

创建一个社交媒体（或聊天应用程序）可能是你作为一个新的软件开发人员需要解决的最典型的挑战。系统核心结构相当简单。

· 一个存储数据的数据库。

· 与客户端通信的网络接口。

· 进行过滤筛选以尽快获取查询数据。

当然，实际情况要比这复杂得多。但此设计的关键点对于所有社交媒体设计来说都是一样的。

那么为什么我们不能直接开发，把它完成呢？

问题是，它必须是一个“去中心化”的系统，只有通过“网络效应”以及开发者生态就一组协议形成工程共识才能成功。否则，我们制造出的问题，恰会与我们想要解决的问题一样。

这就产生了混乱。如果你今天创建出了完美的社交媒体，你要如何说服其他开发者在此基础上进行开发建设？如果开发者不开发出功能，用户为什么会用呢？如果用户不来使用，媒体平台还有什么意义呢？

Gab和Mastodon的例子清楚地表明，只有代码开源是远远不够的。开发过程和标准设计也必须是公开的。否则，一个人就会变成一个小团队（基本都是自愿参与一个活跃的项目），最终会成为这个平台“仁慈的独裁者”。

因为他们必须受这类平台的现实设计制约，在大规模提供产品的同时，他们最终创建了一个小团队，专门设计平台的运行方式。这使得客户端开发人员很难在该平台开发休闲有趣的应用程序。在某些时候，他们还可能会决定设计一些小协议，但最终，他们会碰到相同的障碍。没有人愿意主动在你为特定利基市场设计的平台上进行开发。

此外，存储数据的成本很高。对于“服务器所有者”来说，这需要资源、维护和时间。目前托管Mastodon instance的所有人都是自愿的，用户单纯依赖他们的友好，不会关闭instance。“知识共享”（creative commons）的老问题出现了。

那么我们能做得更好吗？

3、另一种方式：Dumb Nostr

如果我们不开发完美的社交媒体，而只是开发最基本的乐高积木，让开发者就基本标准单元公开达成共识，会怎样？

这就是Nostr所做的。

这么做要通过以下方式：

规定社交数据格式的最小单元（一个event），让开发人员在此基础上自然达成共识。这就是协议的核心。这是每个人参与网络都需要同意的最基本的支撑。

Nostr将这些协议规则定义为NIP，进行了一组指令性NIP陈述，规定了与Nostr协议通信需要实现的规则。

在这些指令性NIP之上，任何人都可以定义可选NIP。中继器可以自由选择它们支持的NIP集。

event数据可以通过未来NIP定义更多的标记项，在标记字段中扩展。

而Events可以看作是一个通用的数据存储。对于可以放入其中的内容没有任何限制。

尽管看起来很奇怪，但如此简单的协议比许多“精心设计”的现有社交媒体替代方案获得了更多开发者的关注。

这个项目已经引起了大量开发人员的兴趣，社区几乎瞬间开发出了一个丰富的包括库、应用程序和中继器在内的生态系统，并且每天都在发展壮大。

Nostr的Telegram群组大约有400个开发成员，而且每天都在增加。

为什么？“因为它非常简单”。

这种简单性使任何感兴趣的人都可以轻松编写JSON streamer，立即让协议与任何现有中继器通信。

人们几乎经常会在基本NIP的基础上添加一些新细节。

协议的简单性允许开发人员快速就开放标准达成共识，并将所有的复杂性放到客户端。整个应用程序体验将由客户端负责，中继器仍将是傻瓜式数据服务器。这允许开发人员在客户端应用程序上快速开发和迭代，同时与任何可用中继器兼容。

这也增强了客户端的兼容性。有可能有两个不同的应用程序，但仍然能够看到彼此的帖子。该平台的核心可以是去中心化的，客户端通过一个简单的存储协议彼此兼容。这就是“dumb server, smart client”模型的巧妙之处。快速达成基本标准，快速迭代客户端应用。

复杂性可以在客户端层定制，而互操作性可以在中继层实现。

4、还需做什么？

一旦我们实现了核心乐高的建设，余下要做的还有DOS保护、中继激励和一些实现用户间nostr订阅数据通信的方法。

 将比特币整合进Nostr

多亏了比特币，中继激励和DOS保护才可以同步完成。

如果基础设施建立在脆弱的“自愿主义”基础上，那么就不可能开发出一个强大的社交网络。正如我们知道的那句话，“如果产品是免费的，那么你自己就是产品”。这些未来的媒体平台应该与比特币进行原生整合。

有个实现比特币与Nostr整合的一站式解决方案，就是使用BDK。一个高性能的比特币钱包库，可足够灵活地处理多种比特币接口和数据库。添加了新的NIP来定义支付请求和支付响应Event类型。

对于发布的每个event，支付可以是一次性的链上交易，也可以是客户端和中继器之间的LN（闪电网络）支付流。（将需要BDK + LDK，目前正在积极开发中）。中继器可以在sats/byte中设置feerate（费率），如果想要义务“自愿”，可以选择将费率设置为0。

这为高度维护的公共中继器提供了一个很好的服务变现方式，同时保护它们免受DOS攻击。

端到端加密订阅共享

请注意，Nostr中继器只是简单JSON数据的转储，通过订阅过滤器获取。这使得nostr成为客户端之间的通用数据共享平台。集成了比特币，现在我们要讨论的是比特币scripts、descriptors、DLC合约和其他通过nostr中继网络共享的比特币DeFi信息。但这些可能是敏感信息，不应该在公共平台上以明文形式共享。

为此，需要一种加密的nostr订阅共享机制。可以是另一个服务器，只用于促进参与者之间的加密订阅数据共享。

可以通过以下方式实现：

· 使用来自目标接收者pubkey的DH共享秘密进行“订阅+中继地址”加密。

· 将加密数据连同接收者的pubkey一起发布到此服务器。

· 接收客户端收到消息，下载并解密数据，获取订阅以从nostr获取实际数据。

· 实际数据也是由相同的共享秘密加密的密文，因此接收方知道如何解密。

这些服务器可以是非常轻量级的，因为它们不需要存储所有历史订阅数据。它们可以定期清除旧数据，甚至可以在知道接收方下载了数据后实时清除数据。这将使服务器成本非常低，而且不需要担心激励问题。

它们不需要遵循任何通用协议，可以通过任一设计自由实现。它们只需要有一种与客户端连接的方式，并知道当发生与客户端相关的事件时何时通知他们。

这些服务器也像nostr中继器一样是抗审查的。如果某个服务器停机，任何人都可以再造一个。因为它们不需要保存历史记录，所以从一个服务器切换到另一个服务器并不会对整个信息流造成影响。

这些服务器也不能利用数据，因为它们所看到的只是一组加密随机数据，所以它们不需要很高的安全性。

最终结果

所以现在把所有这些（Nostr，比特币和加密订阅共享）相结合，我们得到了一个非常强大和默认设置的私人社交网络，可以使用一些非常通用和全局性的协议在参与者之间共享数据。

这使得隐秘的社交网络有可能选择性地向特定的可信实体公开他们的发帖内容。

这些帖子可以是DLC合约、描述多方间多签机制的descriptor、仅向订阅会员公布的DLC预言机，等等。

在这个框架中，“身份”的基本单元是pubkey。pubkey类似于现实世界里的昵称。任何人都可以有随意数量的昵称。如果一个昵称被泄露，可以迅速创建出另一个，就像我们每次付款都要创建一个新的比特币地址一样。

使用pubkey作为昵称，然后可以选择性地向自己的私人可信网络开放。你可以将一个pubkey与你的全局昵称关联（每个人都知道的Twitter操作），然后持有任意数量的并行昵称，仅在特定人群间通信，或者使用特定的应用程序。

与所有这些pubkey相关的数据间保持完全不相关性，可以跨多个nostr中继器分布。

最终模型总结如下：

· 一个高度互操作的、极其简单的中继协议——nostr。

· 一个灵活的框架，可通过中继器可选的升级选项添加新的中继功能。

· 用于传递nostr订阅的加密订阅共享机制。

· 比特币原生集成，方便“货币互联网”和DOS保护同时进行。

· 一个去中心化的发行层，客户端可以发布公共和私有内容。

· 有较好的客户端复杂性来诠释这些内容，并具有应用比特币功能的可生成原生金融合约的UI。

与web3.0不同的是，这一切并不会涉及到另一个“区块链”。

5、前路分析

尽管听起来不错，但我们还没走到那一步。实现这些想法需要大量的工程设计。前进的道路上还有未知问题需要解决。这些中继器和客户端的设计决策需要仔细规划。仅有一个简单的协议是不够的。

中继器应该高效、可靠，经过公开严格的同行评审，并保证基本安全。工作必须公开开展，并且组件应该设计得尽可能灵活，以满足不同的客户端开发人者需求。

如果这个过程需要扩展到专业化的服务，人们可以在自己的服务器上部署这些服务，并会基于此开发出像样的产品，那么我们需要的就不仅仅是业余代码和示例应用程序了。

我们需要的不是另一个很酷的nostr应用程序，而是一个经过深思熟虑的设计卓越的基础设施库，可以让隐秘的超级程序员使用它来开发下一个很酷的集成比特币的nostr应用程序。

6、引入rust-nostr

rust-nostr是一个处于想法阶段的项目，旨在解决上述问题。我们的想法是提供一个完整的nostr基础设施一站式套件，它是模块化的，易于扩展的，具有强大的安全保障，有良好的文档，非常容易让开发人员根据自己的需要进行定制，非常容易下载、部署服务器，易于管理。

整个结构仍处于TBD阶段，但rust-nostr的大概模样如下：

· 一个生成nostrd的binary crate。Nost中继器的轻量级、高效的rust实现。nostrd将附带一组支持的NIP。默认情况下可包含基本的NIP。额外的NIP可以在构建时通过feature flag指定。

· 一个可以用作服务器端nostrd管理器的nostrd-cli。它还可以让nostr协议与任何其他中继器通信，并可作为一个cli nostr客户端被使用。可以通过基本身份验证或cookie身份验证向中继器提供维护入口。

· 一个丰富的nost-API库，包含在项目中，可作为开发人员开发nostr客户端的简便开发工具。然后，这些API可以通过ffi向其他语言公开，并为开发人员提供一站式工具来建设他们的优秀Nostr客户端。

portal是一个加密的nostr订阅共享服务器。portal规范不是项目的组成部分，因为它是一个已解决的问题。这在密码学文献中已经得到了很好的解释，并且有很多开源的候选实现方案。Signal App本身就是portal的一个例子，尽管在这个用例中很难使用。印度的一支本地团队一直专注于这个问题，针对p2p比特币交易的特定用例（称为CypherPost），这已是一个非常合适的portal实现。最终，rust候选实现方案的精简版本将被添加到项目库中。但是人们可以自由地开发并使用他们自己的portal，且仍然与网络的其他部分兼容。

所有这些（portal除外）都将通过BDK和LDK进行原生比特币和闪电网络集成。

为了确保基础设施的所有部分都能始终保持同步，他们将在项目的CI pipeline进行严格的集成测试。

一旦所有这些都安排妥当，就可以使用rust-nostr套件开发各种更复杂的客户端，在各客户端之间开展比特币DeFi业务。

7、结语

到目前为止，这只是一个初步想法，我甚至不知道未来有可能面对什么样的挑战，但我预计挑战不会少。常言道：“细节决定成败”。这似乎是一个雄心勃勃的项目，但并非如此。

通过限制项目范围以提供非常具体的开发工具，这几乎可以通过若干积极的rust开发人员来实现。Rust也是最适合用于此类开发的语言，因为它允许我们在编译器级别严格定义协议规则，从而减少错误空间，同时生成非常简洁且易于审计的代码。

不搭建“产品”，只解决乐高积木的问题，我认为通过这一方式，我们的想法是完全可以实现的。

这个项目可以为比特币创业家开发各种应用铺平道路。应用空间的疆域只受想象力的限制。