Hoodrh

Nostr 基础介绍#

Nostr 是一个非常轻量级的开放协议，“有机会”（根据项目文档）作为一个去中心化的社交媒体平台。协议规范在 NIP（Nostr 改进提案）中定义，可在此处找到。

该协议的基础是一个 WebSocket 服务器（称为 nostr-relay），它处理和存储一个非常简单的数据结构，称为Event. 它看起来像下面这样：

{
"id": <32-bytes sha256 of the the serialized event data>
"pubkey": <32-bytes hex-encoded public key of the event creator>,
"created_at": <unix timestamp in seconds>,
"kind": <integer>,
"tags": [
["e", <32-bytes hex of the id of another event>, <recommended relay URL>],
["p", <32-bytes hex of the key>, <recommended relay URL>],
... // other kinds of tags may be included later
]
"content": <arbitrary string>,
"sig": <64-bytes signature of the sha256 hash of the serialized event data, which is the same as the "id" field>,
}

事件总是被签名（使用 Schnorr sigs）并且它们包含可以具有语义含义的结构化数据。BIP340 中定义的 Schnorr 类型 XOnlyPubkeys （目前与比特币 Taproot 一起使用）在整个协议中用作 “身份”。

nostr-client 是一个可以与 nostr-relay 对话并可以使用 Subscription Filter. Events 过滤器代表客户感兴趣的所有 nostr 集合。

客户无需注册或创建帐户。客户用他们的公钥来标识。每次客户端连接到中继时，它都会提交其订阅过滤器，只要客户端连接，中继就会将 “感兴趣的事件” 流式传输到客户端。

中继可以缓存客户端订阅，但不是必须的。客户应该在 “客户端” 处理所有事情，而中继可能像石头一样笨。

客户不互相交谈。但是继电器可以。这允许中继为它没有的客户端获取数据。客户可以订阅他们连接的中继之外的事件。

乍一看，这给人一种 Nostr 作为协议毫无用处的印象（为什么不只是签名并转储原始 JSON，让客户自己弄清楚呢？），但从更深层次的角度来看，“哑服务器，智能客户端” 模型可以发现具有一些巨大的工程优势，特别是在去中心化协议设计中。

本文档概述了这些愚蠢的服务器、智能客户端和比特币网络、e2e 加密如何结合起来解决 “去中心化社交网络”、DSN（我刚刚想到的流行词）的问题。

问题陈述#

如果您在过去的 2 年里没有生活在岩石之下，那么您已经知道当前的出现以及市场对拥有 “Twitter 替代品” 的强烈呼声。不违背用户动机的社交媒体平台。

这种需求催生了Gab和Mastodon等替代社交媒体平台。Ex Twitter 负责人最近的声明已经暗示这将是下一个需要解决的大问题。所以免责声明：我并不是说这是一个容易解决的问题，我也不认为 N​​ostr 可以解决所有问题。但它至少 “有机会”。

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

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

• 一个存储东西的数据库，

• 与客户端对话的网络接口

• 一些过滤以尽快获取查询数据。

当然，这在现实生活中要复杂得多。但这种设计的关键对于所有社交媒体设计来说都是一样的。那么，为什么我们不能构建它并完成它呢？

问题是，它必须是一个 “去中心化” 系统，只有通过 “网络效应” 和开发者生态系统对一组协议的新兴工程共识才能成功。否则，我们会制造出我们打算解决的同样问题。

这就是事情变得混乱的地方。如果您今天构建了完美的社交媒体，您如何才能说服其他开发者在此基础上进行构建？如果开发人员不构建功能，用户为什么会来？如果用户不来，该媒体平台的意义何在？

Gab 和 Mastodon 的例子清楚地表明，仅将代码开源是不够的。标准的构建过程和设计也必须公开。否则，一个人最终会成为一小群人，大部分人自愿从事激进项目，并最终成为该平台的 “仁慈的独裁者”。

因为他们必须满足此类平台的现实设计限制，同时大规模提供他们的产品，所以他们最终创建了一个专门设计平台方法的小团队。这使得客户端开发人员很难使用该平台的休闲有趣的应用程序。在某个时候，他们不妨决定设计他们的小协议，但最终，他们会遇到同样的障碍。没有人愿意自愿在您为特定利基市场设计的平台上进行构建。

存储数据的成本也很高。“服务器所有者” 需要资源、维护和时间。当前托管 Mastodon 实例的所有人都是自愿这样做的，用户只是依赖他们的友善而不是关闭实例。“知识共享” 这个由来已久的问题出现了。

那么我们可以做得更好吗？

另一种方法，愚蠢的 Nostr 方法#

如果我们不构建完美的社交媒体，而只是构建创建此类事物所需的最基本的乐高积木，并让开发人员就拼图的这个基本标准单元公开达成共识，那会怎样呢？

这就是 Nostr 所做的。

为此，它采用以下方法。

指定社交数据格式的最小单位 (an Event)，并让开发人员之间自然而然地达成协议，以此为基础。这定义了协议的核心。每个人都需要就成为该网络的一部分达成一致的最低限度的主干。

Nostr 将这些协议规则定义为 NIP。并提到了一组 mandatoryNIP。需要实施的规则来讨论 Nostr 协议。

在这些 NIP 之上 mandatory，optional 任何人都可以定义 NIP。中继可以自由选择他们支持的 NIP 集。

通过未来的 NIP 定义更多的标签项，Event 可以在现场扩展数据。tag

可以将 AnEvents 视为通用数据存储。可以放入其中的内容没有限制。

尽管看起来很奇怪，但与许多 “精心设计” 的现有替代社交媒体相比，这样一个简单的协议得到了更多的开发者关注。

该项目已经引起了开发人员的极大兴趣，社区几乎很快就开发了一个包含库、应用程序和中继的丰富生态系统。而且这个名单每天都在增加。

Telegram 聊天室拥有大约 400 名成员，并且每天都在增长。

为什么？“因为它太简单了”。

这种简单性允许任何有兴趣的人轻松编写 JSON 流媒体并开始将协议与任何现有的中继进行对话。

可以在此处找到当前正在运行的 Nostr 继电器的实时列表。

已经存在两个正在进行中的类似 twitter 的应用程序branle和NOSTR-twitter。

人们还几乎定期地在基本 NIP 之上添加新的额外细节。

该协议的简单性使开发人员能够快速收敛于开放标准，并将所有复杂性都放在客户端。整个应用程序体验将由客户端处理，中继将保持哑数据服务器。这允许开发人员在客户端应用程序上快速移动和迭代，同时与任何可用的中继兼容。

这也增加了客户端兼容性。可以有两个不同的应用程序，但仍然能够看到彼此的帖子。该平台的核心是去中心化的，客户端通过简单的存储协议相互兼容。这就是 “哑服务器，智能客户端” 模型的巧妙之处。快速就基本标准达成一致，更快地迭代出色的客户端应用程序。

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

缺失的部分#

一旦我们了解了核心乐高积木的外观。剩下的部分是 DOS 保护、中继激励和一些在用户之间传递 nostr 订阅数据的方法。

将比特币放入 Nostr#

得益于比特币，中继激励和 DOS 保护可以一次性解决。

如果其基础设施依赖于脆弱的 “自愿主义” 基础，则无法建立强大的社交网络。正如我们所知，“如果产品是免费的，那么您就是产品”。应该将这些未来的媒体平台原生集成到比特币中。

做到这一点的一站式解决方案是使用BDK。一个高性能的比特币钱包库，足够灵活以处理多种比特币接口和数据库。添加了一些新的 NIP 来定义 payment request 和 payment response 事件类型。

对于他们发布的每个事件，付款可以是一次性链上交易，也可以是客户和中继之间的一系列 LN 付款。（将需要正在积极开发中的 BDK + LDK）。中继可以以 sats/byte 为单位设置他们的费率，如果他们想 “自愿”，他们可以选择将其设置为 0。

这为高维护公共中继提供了一种通过其服务获利的好方法，同时保护它们免受 DOS 攻击。

端到端加密订阅共享#

请记住，Nostr 中继只是简单 JSON 数据的转储。通过 subscription 过滤器获取。这使得 nostr 成为客户端之间的通用数据共享平台。有了比特币，现在我们谈论的是通过 nostr 中继网络共享的比特币脚本、描述符、DLC 合约和其他比特币 DeFi 信息。但这些可能是敏感信息，不应以明文形式在公共平台上共享。

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

这可以通过以下方式实现：

1. 使用从预期接收者的公钥派生的 DH 共享秘密来加密 [subscription+]。relay-addres

2. 将加密数据连同收件人的公钥一起发布到此服务器。

3. 收件人客户端收到通知，下载并解密数据，获取订阅以从 nostr 获取实际数据。

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

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

这些服务器不需要遵循任何通用协议。可以通过任何设计自由实施。他们只需要有一种方法来连接到客户，并知道何时在与他们相关的事情发生时通知他们。

它们也像 nostr relay 一样抗审查。如果一个出现故障或停止工作，任何人都可以启动另一个。因为他们不必保留历史记录，所以从一台服务器切换到另一台服务器不会影响整体信息流。

这些服务器也无法利用数据，因为它们看到的只是随机的加密 blob，因此它们不需要高度安全。

最终画面#

所以现在结合所有这些，Nostr、比特币和加密订阅共享，我们现在拥有一个非常强大和默认的私人社交网络，可以使用一些非常通用的全球协议在参与者之间共享数据。

这允许人们的隐藏社交网络有选择地向特定的受信任实体开放他们的帖子的可能性。

这些帖子可以是 DLC 合同、描述多方之间多重签名的描述符、仅向订阅成员发布的 DLC 预言机等等。

在这个框架中，“身份” 的基本单位是公钥。公钥类似于现实世界中的别名。任何人都可以有任意数量的别名。如果一个别名被泄露，他们可以快速创建另一个，就像我们为每笔付款创建一个新的比特币地址一样。

使用公钥作为别名，就可以有选择地向您自己的私人可信网络开放。您可以将一个公钥与您的全局别名（众所周知的 Twitter 用户名）相关联，然后使用任意数量的平行别名仅在特定人群之间进行通信，或使用特定应用程序。

与所有这些公钥相关的数据将保持完全无关，并且可以分布在多个 nostr 中继中。

最终总结出来的模型是：

1. 高度互操作且极其简单的中继协议，nostr。

2. 一个灵活的框架，用于使用 optional 中继可以选择加入的升级来添加新的中继功能。

3. 一种加密的订阅共享机制，用于传递 nostr 订阅。

4. 比特币原生集成，同时促进 “货币互联网” 和 DOS 保护。

5. 一个去中心化的发布层，供客户发布公共和私人内容。

6. 解释这些内容的客户端复杂性，并具有使用比特币功能的本地金融合约生成 UI。

与 web3.0 的所有内容不同，这不涉及另一个 “区块链”（我知道这很糟糕）。

前进的道路#

听起来不错，但我们还没有做到。而要实现这些梦想，还需要大量的工程设计。前面有未知的问题需要处理。这些中继和客户端的设计决策需要仔细规划。仅仅有一个简单的协议是不够的。

这些中继应该高效、稳健、在公开场合经过严格的同行评审，并在基本安全级别得到保证。这项工作必须公开进行，元素的设计应尽可能灵活，以满足不同客户开发人员的需求。

如果这个东西需要扩展到人们可以在他们的服务器上部署的专业服务，并以此为基础构建重要的产品，我们需要的不仅仅是爱好代码和示例应用程序。

需要的不是另一个很酷的 nostr 应用程序，而是一个经过深思熟虑和设计的基础设施库，影子超级编码员可以使用它来构建下一个带有 “内部比特币” 的很酷的 nostr 应用程序。

介绍 rust-nostr#

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

整个结构仍然是待定的，但下面是 rust-nostr 的大致轮廓。

1. 二进制箱生产 nostrd. Nostr-Relay 的轻量级高效 Rust 实现。nostrd 将附带一组受支持的 NIP。默认情况下可以包含基本 NIP。可以在构建时通过功能标志指定额外的 NIP。

2. nostr-cli 可用作 nostrd 服务器端管理器的 。它还可以与任何其他中继对话 nostr 协议，并且可以用作 cli nostr 客户端。维护访问可以通过基本或 cookie 身份验证提供给中继。

3. 丰富的 nostr-API 图书馆。包含在项目中，可以用作开发人员构建其 nostr 客户端的简单开发工具。然后可以通过 ffi 将这些 API 公开给其他语言，并将为开发人员提供一站式工具来构建他们很酷的 Nostr 客户端。

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

   所有这些（除了 portal）都将通过 BDK 和 LDK 在其中集成原生比特币 + Lightning。

为了确保基础设施的所有部分始终相互同步，他们将在项目的 CI 管道中进行严格的集成测试。

一旦所有这些都布置好了，就可以使用 rust-nostr 套装来提出各种更复杂的客户端，这些客户端在彼此之间进行比特币 Defi。

结束语#

到目前为止这只是一个原始的想法，我什至不知道可能的未知挑战是什么。我期待很多。正如他们所说的 “细节决定成败”。这似乎是一个雄心勃勃的项目，但事实并非如此。

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

通过不尝试制造 “产品” 而只解决乐高积木，我认为这是可以实现的。

然后，该项目可以为比特币企业家提出各种应用铺平道路。应用空间的限制只限于想象力。

因此，如果您碰巧关心这个问题并想伸出援手，或者如果您有任何一般性的建议或意见，请在 Twitter 上通过 @rajarshimaitra 联系我。DM 已开通。

翻译：Hoodrh

原文地址