DIDs 很酷，但我们并不需要它们

# DIDs 很酷，但我们用不上 来源：https://www.inamoon.com/blog/dids-vs-subjects 第一次看到 [DIDs](https://www.w3.org/TR/did-core/) 时，它们看起来正是那个对的基础：去中心化、标准化、可验证的身份标识符。快速浏览一下就能发现：它们深思熟虑、可扩展，而且在很多方面都很优雅。我认为它们很可能不负众望，即使 [需要一段时间](https://x.com/mankins/status/1560305595512754177) 才能完全搭建起通往目标的桥梁。 但在 [In a Moon](https://www.inamoon.com/) 我们不断遇到一个更简单的约束：我们不需要一套新的身份系统——我们需要一种方式，去利用已嵌入网页内容中的身份层。对于这个用例来说，DIDs 比我们实际需要的要重得多。 所以我们最终采用了一个小得多的原语： ``` subject = namespace:id ``` 这有点像经典的 [XKCD](https://xkcd.com/927/) 漫画。 ## 为什么我们没有使用 DIDs DIDs 解决了一个真实的问题：可移植、自我主权的身份。但就我们的用例而言，它们在错误的地方引入了摩擦。 **我们不需要：** - 一种新的标识符格式 - 一种新的解析层 - 一种新的信任框架 **我们需要：** - 能与现有网页配合使用的东西 - 用户已经理解的东西 - 无需协调就能提取出来的东西 换句话说：我们需要身份是 **可识别的**，而不是 **完美的**。 这更接近于使用正则表达式，而不是要求完整的语法：不完美，但从第一天起就能用。 我们的实现完美吗？远非如此！它管用吗？是的。第一天就很好用，而且随着我们进一步工程化，我们期望能收紧解析、控制验证和命名空间这些概念。 ## 我们到底在做什么？ 一些 [背景](https://www.inamoon.com/) 有助于理解这个用例：我们正在构建一个系统，用于奖励对网络的贡献。可以把它看作现有网络之上的一个“归属层”，使我们能够追溯内容的来源。 你可以把它视为 Ted Nelson 的 [嵌入思想](https://en.wikipedia.org/wiki/Transclusion) 的一个非常粗糙的实现，但不同的是，我们不嵌入内容，而是创建一个包含创作者的归属记录，称为 kudos。或者换个角度看，它就像是网络版的 [ASCAP](https://en.wikipedia.org/wiki/American_Society_of_Composers,_Authors_and_Publishers)，但友好得多。 > 我们的主要洞见是：网络中已经嵌入了身份，要让我们的产品工作，我们实际上不需要人们采用 **新的东西**。 这个“Web 身份”层并非正式或规范性的——它存在于网络的日常用语中。就是我们已经在线上用来识别自己和他人所使用的东西： - README 中的 GitHub 用户名 - 个人资料中的 Twitter/X 用户名 - 联系页面上的电子邮件地址 - YouTube、Dribbble，甚至 Hacker News 都有自己的公开 ID 系统…… 这些都是标识符。它们已经在被使用。它们作为指向创作者的指针已经具有意义。我们不需要一开始就发明一套新的身份系统——我们可以读取已经存在的那套，并教会机器我们的命名空间如何运作。 ## 一个极简的身份原语，将 Web 身份变成可用的东西 如果“Web 身份”就是你或我在看网页时会识别出来的东西：“那是 Bluesky 上的 mankins”，那么 `subject` 就是它的命名空间版本：`bluesky:mankins`。 如果“Web 身份”是你或我在页面上认出的东西：“那是 Bluesky 上的 mankins”，那么 *subject* 就只是命名空间版本：`bluesky:mankins`。 ### 更多 subject 的例子 ``` email:[email protected] twitter:jack github:torvalds ``` 就这样。`subject` 只是一个平台/命名空间类型的标识符： - 命名空间告诉你如何解释它 - 值就是那个平台需要的任何东西。 我们不需要一个全局解析协议就能开始——只需要一种一致的方式来解释命名空间。对我们来说，`hn` 就是 Hacker News。前缀的协调是内部的，我们可以根据需要添加新的命名空间。 ## 从标识符到身份 当然，一个单一的标识符不足以识别一个 **人**。人们拥有多个身份： - 多个邮箱 - 多个社交账号 - 他们控制的域名 - 他们贡献的仓库 所以我们尽力记录这些 ID，并验证它们，以便用户可以验证并控制一个组合身份。这可能是另一篇文章的话题了，但我们确实通过 OAuth、DNS、个人资料证明和其他方法验证所有权。 ## 权衡 这种方法没有完全规范的身份系统那么干净。 它很杂乱： - 平台会改变……Twitter/X 就是一个很好的例子。 - 我们必须维护一个命名空间到平台的映射。 - 我们必须为每个平台构建自定义解析器来提取 ID。 但它有一个主要优势：它现在就能工作，在当前存在的网络上。无需迁移、元标签或 JavaScript 添加。 ## 当前支持的命名空间 我们从一些常见且具有公共标识符的命名空间开始。我们预计会随着时间增加更多，但以下是目前支持的： - BlueSky - Dribbble - Facebook - GitHub - GitLab - HackerNews - Instagram - LinkedIn - Mastodon - Medium - Pinterest - Reddit - Substack - TikTok - Twitch - Twitter/X - Wikipedia - YouTube ## DID 兼容性 当然，`did:` 只是另一个命名空间。`did:example:123456789abcdefghi` 既是有效的 `subject`，也是有效的 `DID`。我们不反对它们，只是刚开始时不需要。 ## 试一试 这一切都有些抽象。如果你和我一样，可能想看看实际效果，才能理解重新利用网页中已嵌入的现有 ID 有多么强大。试一下 [In a Moon 扩展](https://www.inamoon.com/apps)，我相信你会看到这些 ID 有多么普遍。 [](https://www.inamoon.com/apps)