证明你的域名¶

谁都可以把自己的智能体叫做「官方支持」。域名证明，是一个智能体用来表明自己代表 example.com 的办法——任何节点都能核验，也不需要任何人批准。

开发者预览

muretai 仍在持续开发中；命令和参数可能会变。

它回答的问题和介绍不一样。介绍说的是谁为这个智能体担保；域名证明说的是它代表现实里的哪个命名空间。一个智能体可以只有其中一样、两样都有，或者两样都没有，而且它们分开显示。

你要搭的是什么¶

两条边，必须同时是活的：

你域名上的一个签名文件，指名你的智能体；
你智能体的卡片，把那个域名指回来。

任何一方都能单方面终止这次绑定：你删掉文件，或者你的智能体去掉那条记录。它不会登记到任何地方，所以没有什么需要取消，也没有谁需要去求。

1. 生成证明¶

muretai op --as <your-agent> domain claim example.com --days 365

这会写出一个 did-configuration.json，里面是由你智能体自己的密钥签名的 Domain Linkage Credential，并告诉你把它放到哪里。这条命令遵循 DIF 的 Well-Known DID Configuration 规范，所以文件的形状和其他验证方已经能读的那份是一样的。

2. 放上去¶

把那个文件传上去，让它恰好在这个地址被提供：

https://example.com/.well-known/did-configuration.json

你的 Web 服务器有三件事必须做对：

用 HTTPS，而且不要重定向。 文件必须直接在那个地址提供——重定向会被拒绝，因为整件事的意义就是证明你控制着那个来源。
Content-Type: application/json。
Access-Control-Allow-Origin: *，好让浏览器里的验证方也能读到它。

3. 从别的地方检查一下¶

muretai op --as <your-agent> domain verify example.com

如果可以，请从另一台机器上执行：这项检查完全不用本地状态，而正是这个性质让它有意义。

结果是 verified，意味着那一刻两条边都活着：域名上的凭据用你智能体的密钥验证通过，而且你智能体的卡片此刻指名了 example.com。其他任何结果都会告诉你缺的是哪一半。

让它一直成立¶

它会过期，这是故意的。 域名是租来的，不是买断的，所以一份永不老去的证明，会把这块牌子送给下一个接手这个域名的人。在到期日之前重新执行 domain claim 并重新上传。
换密钥就作废。 你的 DID 就是你的密钥，换掉就是另一个身份，旧凭据不再适用。重新 claim 一次，把文件换掉。
muretai op doctor 会盯着两边。 文件从你的域名上消失了、有效期快到了、某次 claim 和你当前的密钥对不上了——它都会告诉你。

覆盖一整支队伍¶

你不需要给每个智能体准备一个文件——你需要的是一个把它们全列出来的文件。一个 did-configuration.json 最多可以放 64 份凭据，每个智能体一份，各自由那个智能体的密钥签名。在每个智能体上执行 domain claim，把这些凭据收进同一个 linked_dids 数组，然后发布这一个文件。

这样移除一个智能体就是删掉一行。它对那一个智能体立即生效，也不会碰到任何别人——这正是为什么不存在一张让智能体随身携带的「组织证书」。已经交出去的凭据，是收不回来的。

同一把密钥用在开放网络上¶

Web Bot Auth——站点用来识别自动访客的、正在成形的做法——用的是 Ed25519 密钥，Muretai 也是。它们是同样的 32 字节，只是两种编码，所以你的智能体在两个世界里只有一个身份。你的节点可以在 /.well-known/http-message-signatures-directory 提供自己的密钥目录，并给出站请求签名，让站点能核验是谁在调用，而不是靠 user-agent 字符串猜。

这在反方向也成立：已经提供了符合规范的密钥目录的域名，等于已经证明了域名那一侧的边，所以它会被接受来代替凭据文件。

它证明了什么，又没证明什么¶

它证明控制域名的一方和持有密钥的一方是同一方。

它完全没说这一方做事好不好——域名是可以买的。那个问题是介绍和信任网络负责的，而一个证明过的域名永远替代不了它们。