Nostr Wallet Connect

安娜在听播客，想通过 Lightning Network 给作者一小笔钱。有了 NWC，播放器可以直接请求她的钱包付款。钱包服务先检查连接权限，再执行获准的请求。NWC 不决定谁保管比特币密钥：另一端可以是安娜自己的节点，也可以是替她保管资金的服务。因此，同样的“连接钱包”按钮，背后可能是完全不同的资金控制方式。根据所授予的权限，应用还可能无需逐笔重新确认就能发起操作。 [1] [2]

钱包通常提供 QR 码或文本连接串，技术上称为 URI。其中包含钱包服务的公钥、中继地址，以及 secret，也就是本次客户端连接的私钥。它不是钱包的 seed（初始秘密值），也不是用于恢复钱包的 Seed Phrase（助记词）。但它同样不是可以公开分享的普通链接：拿到可用副本的人可能行使相同权限。潜在损失取决于获准的功能与限额。为不同应用建立独立连接，既便于识别和分别撤销，也能减少连接之间被关联的机会。 [1]

有的应用只需读取余额，有的还要发送资金，两者的权限不同。公开的 info 事件公布服务支持的能力，get_info 则返回某个具体连接可用的方法。方法就是有名称的指令：pay_invoice 请求付款，make_invoice 创建支付请求，lookup_invoice 查询其状态，get_balance 读取余额。get_info 本身也属于核心功能。历史记录、keysend（无需预先创建发票的支付）和通知属于可选扩展。因此，服务器支持一条指令，并不代表每个连接的应用都有权执行它。 [1] [3] [5]

安娜可能只想给播放器有限的预算。如果服务提供支出、方法或有效期限制，就必须由服务自身执行。只在播放器界面上显示一个数字，挡不住应用发送不同的请求。还要确认额度是一次性的还是会重置，以及手续费如何计入。安娜不再使用该应用时，应在钱包服务端撤销它的权限。仅仅删除应用或移除本地连接，并不能证明访问权已被取消。撤销会阻止未来的请求，但不会撤回已经完成的付款。 [1]

Lightning 发票是支付请求，例如使用 BOLT11 格式，并不是已付款证明。NIP-47 用 msat 表示金额和手续费，它是 satoshi 的千分之一：1000 msat = 1 sat。混淆单位会造成千倍差异。make_invoice 仅创建请求；成功的 pay_invoice 返回 preimage。对这个值计算哈希，会得到一个简短的校验值。它必须与发票中的支付哈希一致；因此，返回的 preimage 可作为支付完成的凭据。错误响应使用 error。状态可以通过 lookup_invoice 查询。应用必须处理真正的执行结果，不能只是发送了消息就显示成功。 [1]

安娜点击付款，但应用没有收到回应。Timeout 表示等待超时，并不说明钱发生了什么。NWC 的请求与响应使用临时事件，中继断开或服务不可用可能让消息丢失。但也可能付款已经完成，仅响应丢失了。因此，应先通过 lookup_invoice 或直接在钱包里核实状态。没有回复并不等于失败。新的请求也不能自动视为原操作的安全重试；先弄清原操作的结果。 [1]

应用与钱包交换加密消息。当前协商优先选择 nip44_v2；已弃用的 nip04 仍为兼容性保留。缺少 encryption 标签意味着旧模式。然而，NIP-44 不提供 forward secrecy，也就是长期密钥日后泄露时对过去通信的保护。中继还可能看见事件类型、标签、连接的公钥和时间。因此，NWC 不应使用用户在 Nostr 上发布内容的主要身份密钥。独立密钥有助于减少支付与公开资料之间的关联，并不保证完全匿名。 [1] [4]

普通用户不必记住消息编号，但开发集成时这些编号很重要。Info 使用 kind 13194，请求使用 23194，响应使用 23195。kind 表示事件类型。p 标签指明对方，响应中的 e 标签指向原始请求。客户端要验证签名、预期的钱包服务公钥、请求对应关系，以及 result_type，即结果所属的指令名称。不能把来自中继的任意消息都当作确认，否则别人的响应或另一项操作的响应，就可能被误认为此次付款的结果。 [1]