NIP20

命令结果

draft optional author:jb55

将事件提交到中继时，客户端目前无法知道事件是否已成功提交到数据库。该 NIP 引入了命令结果的概念，除了提供有关事件是否被接受或拒绝的更多信息外，命令结果与通知类似。

命令结果是具有以下结构的 JSON 对象，当事件成功保存到数据库或被拒绝时，将返回该对象：

当事件重复且已保存时，中继必须返回 true。在这种情况下， message 应以 duplicate: 开头。

当事件被拒绝且未保存时，中继必须返回 false。

message 应提供有关命令成功或失败原因的其他信息。

如果公钥或网络地址已被阻止、禁止或不在白名单上，则 message 应以 blocked: 开头。

如果事件无效或不符合某些特定条件（创建 _ 的时间太远、ID 错误、签名错误等），则 message 应以 invalid: 开始。

如果事件没有遇到一些工作证明困难，则 message 应从 pow: 开始。客户端可以在此时查询中继元数据以检索所需的发布难度。

如果事件由于速率限制技术而被拒绝，则 message 应以 rate-limited: 开头。

如果由于服务器问题而无法保存事件，则 message 应以 error: 开始。

除非出现故障，否则不会使用 OK 响应来确认短暂事件。

如果事件或 EVENT 命令格式错误且无法解析，则应使用通知消息而不是命令结果。此 NIP 仅适用于非格式错误的事件命令。

例子

事件已成功写入数据库：

由于以下原因，事件已成功写入数据库：

由于 IP 筛选器，事件被阻止

由于公钥禁止，事件被阻止

事件被阻止，pubkey 未注册

事件被拒绝，速率受限

事件被拒绝， created_at 距离太远

事件被拒绝，工作证明不足困难

事件保存失败，

客户端处理

messages 是为人类设计的，带有 reason: 前缀，以便客户端可以稍微更智能地处理它们。例如，由于某种 rate-limited: 原因，客户端可能不会显示任何内容，只是在较长的超时时间内再次尝试。

对于 pow: 前缀，它可以查询中继元数据以获得更新的难度要求，并在后台重试。

对于 invalid: 和 blocked: 前缀，客户端可能希望将它们显示为样式错误弹出窗口。

前缀包括一个冒号，以便可以通过获取后面 : 的所有内容并对其进行修剪来将消息与前缀完全分离。

未来扩展

这个提议应该在将来扩展到支持更多的命令，例如 req 和 auth.它们被排除在这个初始版本之外，以使事情变得更简单。