Nostr

安娜在 Nostr 上找到了想关注的作者。后来，她觉得当前应用不再适合自己。如果能在另一款应用中安全地使用同一把私钥或连接的签名设备，她就可以保留原来的身份。公钥让别人识别她并验证签名，私钥则允许持有者以她的名义签名。因此，npub 与 nsec 的区别至关重要。按照 NIP-19，它们分别是公钥和私钥的 Bech32 编码形式。NIP 是按编号区分的文档，用来描述 Nostr 的规则与扩展。编码不是加密：nsec 不是可以随便分享的个人主页链接。保留身份也不等于新应用一定能找回全部旧内容，或导入每项设置。 [2] [7]

应用又称客户端，它签署内容后，将其发送到选定的中继服务器。中继服务器接收消息，并按自己的规则保存或转发。彼得的应用连接中继服务器，请求他感兴趣的内容。这里没有唯一的中心服务器，也不要求每台服务器都复制全部消息。技术上，客户端与中继通过 WebSocket 这种保持打开的连接通信：EVENT 传送消息，REQ 建立订阅，OK 表示接受或拒绝。即使收到肯定的 OK，也不代表彼得已经收到内容，更不保证永久保存。EOSE 表示该查询中已保存结果的发送结束，订阅随后仍可接收新消息。 [1] [7]

彼得收到消息时，应用会检查签名是否对应所列公钥，以及签名覆盖的数据是否被修改。这既不证明消息属实，也不证明作者的现实身份。创建时间同样由作者填写，因此不是独立的可信时间戳。想进一步了解技术细节，可以看名为 event 的记录：pubkey、created_at、kind、tags 和 content 分别表示公钥、时间、类型、标签和内容。按照严格规定的格式排列这些数据后，SHA-256 生成一个简短的校验值 id，用来帮助识别已签名数据是否发生变化。sig 字段存放采用 BIP340、在 secp256k1 曲线上生成的 Schnorr Signature，也就是施诺尔签名。它表达的是“对应密钥的持有者签署了这些数据”，而不是“这句话值得相信”。 [1]

很长的公钥不方便记忆。NIP-05 允许把它与一个类似电子邮箱地址的标识符关联起来。应用向相应域名查询该名字对应的公钥，再与个人资料中的公钥比较。验证的是这项域名关联，而不自动证明某人的真实姓名、声誉或可靠性。域名运营者以后可以改变对应关系。如果安娜已经关注某人，判断身份的依据应继续是原来的公钥；同一个名字被分配给新公钥，不应悄悄改变她关注的人。化名性是使用稳定标识代替法定姓名，并不保证匿名。 [3]

彼得不必下载所有消息。他可以发送过滤条件，例如只看某些作者发布的某类内容。同一个过滤器内的不同条件采用 AND，必须同时满足；同一条件允许的多个值是 OR 关系，表示任选其一。同一次 REQ 中的多个过滤器也按 OR 组合，符合任意一个即可。limit 限制的是最初返回的已保存结果数量，并不自动限制订阅以后收到的新消息。NIP-01 在事件和过滤器中使用公钥的十六进制写法，而不是面向用户的 npub 格式。没有搜索结果，可能是过滤条件、所选服务器或它保存的历史所致，不能据此认定该内容在任何地方都不存在。 [1]

安娜修改了个人简介，希望别人看到新版。为此，Nostr 区分中继应保存哪些记录。对于可替换事件，中继为相同的 pubkey 与 kind 组合选择最新记录。可寻址事件还加入 d 标签的值，用来区分同一作者的不同文档等。如果可替换记录的时间相同，建议保留字典序较小的 id，也就是按其书写形式排序时靠前的那个。临时事件称为 ephemeral，甚至不要求保存。这些属于约定，中继的实际行为可能不同。因此，Nostr 不是一个让全网对唯一、不可更改的历史达成一致的账本。 [1]

安娜发现自己把本想保密的内容公开了。NIP-09 允许她发出签名的删除请求。客户端在执行前，必须确认请求与原内容属于同一公钥；陌生人不能仅凭引用安娜的内容就将其删除。配合的服务器和应用可以移除内容或停止显示，但请求无法抹去所有副本、截图或独立档案。在一个应用里隐藏了内容，也不说明其他服务器已不再提供它。因此，发布了什么比界面上有没有“删除”按钮更重要。 [4]

任何拿到公开内容的人都能阅读它，签名本身不会隐藏正文。私信需要额外规则。NIP-44 描述内容加密，NIP-17 则规定如何封装、传递消息并增加保护层。这不等于自动匿名：网络地址、时间和应用行为仍可能透露信息。这种加密也不提供 forward secrecy，即长期密钥日后泄露时对过去通信的保护。拿到所需私钥以及以前记录的密文，就可能读出过去的消息。因此要确认具体应用实际支持哪些扩展；仅凭“Nostr”这个名称，无法判断其隐私保障。 [5] [6]