Bitsocial 与 Nostr

Nostr 并不能干净地归入联邦式或区块链这两类。用户的账号不是由实例发放的，也没有链、共识、gas 或全局排序。更贴切的说法是，Nostr 是基于中继的社交媒体：用户持有密钥对，为事件签名，并把事件发布到中继，而中继就是存储并提供这些事件的普通服务器（NIP-01）。Nostr 自己的 README 也写明，它并不依赖点对点技术。

在一个重要方面，这让 Nostr 比联邦式或区块链系统更接近 Bitsocial：身份是加密的，而且可携带。差别在于数据层，以及由谁把守入口。

Nostr 的工作原理

• 事件与中继。 每条帖子、个人资料或回应都是一个签名的 JSON 事件。客户端通过 WebSockets 把事件发布到中继，并带着过滤条件订阅；中继存储事件并把它们返回给客户端。中继之间互不通信。
• 复制。 用户通常会发布到多个中继。2023 年一项针对 712 个中继的研究发现，平均每条帖子存在于其中 34.6 个中继上（Wei 和 Tyson）。
• 查找某人的帖子。 用户会发布自己写入和读取的中继列表（NIP-65），客户端则从该用户的写入中继获取其帖子。
• 身份。 每个用户就是一把使用 Schnorr 签名的 secp256k1 密钥。规范没有定义密钥轮换或恢复，因此丢了密钥就等于丢了账号。可选的 name@domain 标识符（NIP-05）通过该域名 Web 服务器上的一个文件来核验。
• 群组。 推荐的社区机制是基于中继的群组（NIP-29）：由一个中继托管群组，在接受帖子之前执行群组的成员和发帖规则，并为群组元数据签名。较早的版主审核制社区（NIP-72）现已被标记为不推荐，改用 NIP-29。
• 垃圾信息控制。 每个中继自行选择入口门槛：工作量证明（NIP-13）、鉴权与白名单（NIP-42）、付费或速率限制。客户端再加上静音列表和信任评分。
• 媒体。 图片和视频上传到单独的 HTTP 文件服务器。

两者的区别

谁存储并提供帖子

在 Nostr 中，中继就是存储与分发层：每条帖子都得有一台服务器让它保持在线。在 Bitsocial 中，HTTP 路由器只负责帮客户端找到对等点。它们不存储帖子、个人资料、社区元数据或审核状态；客户端从社区的节点以及为它做种的对等点获取内容。参见点对点协议。

谁把守入口

Nostr 的写入门槛掌握在中继运营者手中。在 NIP-29 群组之外，被一个中继拒绝的密钥可以把同一事件发布到任何愿意接受它的中继，而读者看到什么，取决于他们的客户端从哪些中继读取。NIP-29 群组更接近 Bitsocial 社区：由群组的宿主中继接受或拒绝帖子。但群组角色能做什么仍由中继定义，而且除非另一个中继同意接手，群组的历史会一直绑定在这个中继上。

在 Bitsocial 中，社区是拥有自己密钥对的加密对象。社区的节点运行所有者选定的任何挑战，并把已接受的状态发布到点对点网络中。参见自定义反垃圾邮件挑战。

运行基础设施

中继是一台拥有域名和 WebSocket 端点的服务器，热门中继要承担其所提供内容的存储和带宽成本。2023 年的那项研究估计，约 95% 的免费中继无法靠捐款覆盖成本。Bitsocial 社区节点可以在消费级硬件上运行，读取社区的对等点也能帮忙分享它。

浏览器

Nostr 网页客户端直接与中继建立 WebSocket 连接，因此不需要应用服务器。Bitsocial 网页应用在标签页中运行一个点对点节点，并从对等点获取内容。参见浏览器点对点网络。

旧内容

Nostr 帖子在中继之间被广泛复制，这有助于旧帖子留存下来。Bitsocial 保留社区的最新状态，不保证旧内容永久留存。

对比

问题	Nostr	Bitsocial
类别	基于中继的协议	点对点社区网络
身份	secp256k1 用户密钥，规范中没有轮换机制	用户和社区各自使用 Ed25519 密钥对
帖子存放在哪里	作者选择的中继，通常有很多个	社区所有者的节点，以及读取并为其做种的对等点
谁让它保持在线	中继运营者	社区所有者的节点，加上协助做种的节点
社区	由中继托管的群组（NIP-29）	一等对象，由其节点接受或拒绝帖子
垃圾信息控制	各中继的策略：工作量证明、鉴权、付费、白名单、速率限制	帖子被接受之前须通过所在社区的挑战
审核	中继策略、客户端静音列表、标签和举报	社区所有者审核自己的社区；应用自行决定显示什么
名称	通过 HTTPS 核验的可选 name@domain 标识符	解析到密钥的 .bso 和 .eth 名称
浏览器	中继的 WebSocket 客户端	普通浏览器标签页中的点对点节点
主要取舍	身份可携带且复制广泛，但可用性与策略取决于中继	对中继的依赖更少，但旧内容不保证永久留存