Nostr

事件包含 pubkey、created_at、kind、tags、content、id 和 sig。NIP-01 对严格规定的序列化结果使用 SHA-256 生成 id，并采用 secp256k1 上的 BIP340 签名。客户端验证完整性和密钥授权。created_at 由作者填写，不是独立时间戳，也不证明内容真实。 [Nostr — NIP-01: Basic protocol] [fiatjaf — Original Nostr description]

客户端通过 WebSocket 发布 EVENT，并用 REQ 订阅。OK 表示该中继接受或拒绝事件。EOSE 表示已存储事件的列表结束，不一定终止对新事件的订阅。这些消息都不能确认收件人已收到、全网已复制或数据将永久保存。 [Nostr — NIP-01: Basic protocol]

同一个过滤器内，事件必须满足所有条件：作者与类型之间是 AND。一个 REQ 中的多个过滤器按 OR 组合，满足其中一个即可。limit 限制初始列表，不限制未来事件数量。查不到结果可能只是中继历史不完整，而非事件不存在。 [Nostr — NIP-01: Basic protocol]

可替换事件按 pubkey 和 kind 比较，可寻址事件还包含 d 标签。新版可以取代旧版；时间相同时保留字典序较小的 id。临时事件不预期被保存。这些规则描述中继行为，而非不可变的全球档案；具体实现可能不同。 [Nostr — NIP-01: Basic protocol]

NIP-19 使用 Bech32 向用户展示数据：npub 表示公钥，nsec 表示私钥。编码不是加密。因此分享 nsec 就是在交出秘密密钥，而不只是分享个人资料链接。NIP-01 的事件和过滤器使用十六进制公钥，不使用 npub 展示形式。 [Nostr — NIP-19: Encoded entities]

NIP-05 根据域名响应，把类似邮箱的名称与公钥关联。它证明的是这种关联，而非真实身份或诚信。客户端应继续关注原公钥：如果域名把名称改为对应另一公钥，不应自动用新公钥替换原来关注的资料。 [Nostr — NIP-05: Internet identifiers]

NIP-09 定义作者请求删除自己事件的方式。客户端隐藏事件前，应核对原事件与请求的公钥相同。中继和客户端可以处理请求，但协议无法删除所有已下载或另行保留的副本。某个界面中的删除不能证明全局擦除。 [Nostr — NIP-09: Deletion requests]

NIP-44 定义加密 payload，并非完整私信系统；NIP-17 添加封装及投递规则。单独使用 NIP-44，在密钥日后泄露时不提供 forward secrecy。即使内容加密，网络地址、时间和客户端行为仍很重要。必须按应用区分具体 NIP 的支持情况。 [Nostr — NIP-44: Encrypted payloads] [Nostr — NIP-17: Private messages]