分布式身份

# 分布式身份识别 来源：https://jyn.dev/distributed-identity 我们都听过那些处理姓名与技术的故事（https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/），但我们仍需坚持。在这个故事中，我们将穿越Git提交历史与生活事件的荆棘，最终使用ATProto来驯服它们。 ## 让我们编写一个用户故事 https://jyn.dev/distributed-identity#let-s-write-a-user-story 假设你有一个大型Git仓库。成千上万的提交，数百个issue，数十个PR。现在假设你的一位贡献者——注意，不是维护者，只是偶尔帮忙的人——名叫Andrea P. Researcher <[\[email protected\]](https://jyn.dev/cdn-cgi/l/email-protection)。Andrea在Greenfield & Co找到了新工作并更换了邮箱。她向你提出请求：其实，我不太喜欢之前的工作，你能把提交历史中的邮箱更新成新的吗？现在你遇到一个小问题：Git是一个默克尔树（https://wyag.thb.lt/#merkle-dags），将所有历史提交都封存在琥珀之中。不进行“强制推送到默认分支”，就无法更改任何历史提交，这会导致所有提交哈希、分布式检出和开放的PR失效。别担心，你说！Git的作者们预见到了这一点。你拥有完美的工具：git mailmap（https://git-scm.com/docs/gitmailmap）。Andrea说太好了太好了，并添加了一个条目： ``` Andrea P. Researcher <[[email protected]]> <[[email protected]]> ``` --- 现在，Andrea结婚了，她的婚前姓变成了Locksmith。但她仍在Greenfield & Co工作，所以邮箱没变。她回来问道：你能把我结婚后的提交改成Andrea Locksmith，但之前的保留为Andrea Researcher吗？你回答说，不行，mailmap不是这样工作的……Git通过（姓名，邮箱）元组来识别你，没有日期的概念。她有些不满，但这也不是什么大事。她使用mailmap将她的提交统一改为Andrea Locksmith（对于`<[[email protected]]>`的更改），而`conglomerate`邮箱的提交则保持不变。 --- Andrea认识了一些朋友，去看电影、演出、读书，并对自己有了一些新的认识。她回来说，嘿，我有个消息，嗯，我的新名字是Bobby。你能更新我所有的提交吗？你指向mailmap，她说不行不行，那会在仓库顶部保留我被弃用的姓名。你就不能改变*实际数据*吗？听着，这对我很重要。1（https://jyn.dev/distributed-identity#fn-1）你道歉了，确实感到抱歉；但你看着300个开放的PR，`.git-blame-ignore-revs`（https://docs.github.com/en/repositories/working-with-files/using-files/viewing-and-understanding-files#ignore-commits-in-the-blame-view）中硬编码的提交哈希，以及你写的无法处理强制推送的合并工具，你只是……你只是不想考虑修复这一切需要多少努力。Bobby理解，他真的理解，他最终还是创建了一个mailmap条目。尽管如此，他现在的贡献减少了。 --- Bobby搬到了德国，了解到那里有一个叫GDPR（https://www.edpb.europa.eu/sme/learn-the-basics/data-protection-basics_en#does-the-gdpr-apply-to-your-organisation）的有趣东西。他的一个朋友告诉他，听着，你有权利使用你选择的名字，知道吗？这是真实存在的、受法律保障的合法权利。现在Bobby回来说“我希望你把我的名字从仓库中移除，因为这是个人的个人数据。”好吧，你*不完全*确定GDPR是这样运作的（也许你有“合法利益”？你确定Bobby不是你提供的“产品或服务”的对象吗？）。但无论如何，律师很昂贵，你宁愿不麻烦，尤其是因为，嗯，Bobby确实有充分的理由。而且这会造成糟糕的公关，*这个*不是你想因此失去贡献者的事情。于是你搞清楚如何使用`git-filter-repo`（https://github.com/newren/git-filter-repo），更新`.git-blame-ignore-revs`，强制推送到`main`，写一篇博客告诉所有人如何rebase他们的PR，然后发现你在文档中硬编码了提交哈希，于是又回头去修改那些，又发现你在一些博客文章中也硬编码了哈希，所以现在你必须更新*那些*，唉。好吧。这大概就是全部了。Bobby很高兴，你为他的高兴而高兴，你挤出一丝勉强的微笑。然后他的朋友Charlie来了，说其实那挺好的，你也能为我做吗？ --- ## 我们在解决什么问题？ https://jyn.dev/distributed-identity#what-problem-are-we-solving Bobby提出了三个要求： 1. 事后更改姓名和邮箱。 2. 事后以基于时间而非基于身份的方式更改姓名。 3. 事后更改姓名，使得之前的姓名无法被检测到。 Git可以提供1，但不能提供2或3。 --- ## 人们尝试过如何解决这个问题？ https://jyn.dev/distributed-identity#how-have-people-tried-to-solve-this Git在这里给你带来了巨大的麻烦！如果这种情况再发生两三次，你甚至可能愿意切换到另一个能更好支持此功能的工具。而且——这是什么？——有个叫`hg censor`（https://www.selenic.com/mercurial/hg.1.html#censor）的工具！它说： > censor命令指示Mercurial在给定版本处擦除文件的所有内容，而不更新变更集哈希。这允许现有历史保持有效，同时防止未来的克隆/拉取接收到被擦除的数据。censor的典型用途是出于安全或法律要求，包括： > - 密码、私钥、加密材料 > - 许可已过期的授权数据/代码/库 > - 个人身份信息或其他私人数据 完美，完美，除了*等等*，它说的是**文件内容**。提交的作者实际上*不是*文件内容。它是附加在提交本身的元数据。该死。太接近了。 ## 我们如何解决它？ https://jyn.dev/distributed-identity#how-can-we-solve-it 嗯，`hg censor`到底是如何工作的？ > 被审查的节点会在需要物化被删除的数据时中断mercurial的典型操作。一些命令，如hg cat/hg revert，在被要求生成被审查的数据时会直接失败。其他命令，如hg verify和hg update，必须能够容忍被审查的数据才能以有意义的方式继续运行。这类命令只在配置选项“censor.policy=ignore”允许的情况下才容忍被审查的文件版本。 哦。呃。他们正在破坏默克尔树的“加密哈希”部分。这没关系？可能吧？我们不*真的*需要`hg verify`（https://mercurial-scm.org/repository-corruption）工作。由于与“filelogs”（https://aosabook.org/en/v1/mercurial.html#:~:text=the%20three%20revlogs）相关的复杂原因，这不会让我们搞出什么大乱子；我们可以损坏`hg log --follow`，但也就这样了。但如果我们将同样的方案扩展到元数据，情况会更糟，我们可能会损坏`hg log`本身，指向恶意的历史。它*需要*以这种方式工作吗？让我们通过对比在线工作的通常方式来考虑我们想要的属性： 1. 人们可以更改自己的姓名和邮箱。 2. 人们可以删除自己的账户。这通常显示为用户发帖`[deleted]`，或`@ghost`用户名。 3. 人们可以（通常）删除其帖子的内容；有时管理员会保留编辑历史。 4. 人们可以（很少）删除帖子本身，使得无法区分“这里曾经有个帖子”和“这里从未有过帖子”。 `mailmap`让我们实现了1，某种程度上。它仍然很容易被追踪。`hg censor`让我们实现了3。目前还没有东西能让我们实现2或4。4可能不是我们在这里太关心的事情。“删除这次提交的所有痕迹，包括它存在过的事实”似乎不是特别必要。但更好地支持1和2会非常好。 ## 现在她回到了ATmosphere https://jyn.dev/distributed-identity#now-she-s-back-in-the-atmosphere 我有好消息：已经有一个在线身份服务可以做到这一点了！（不，不是OpenID Connect。）它叫做ATProto（https://atproto.com/），是驱动Bluesky（https://bsky.app/）的协议。ATProto具体如何工作有点超出本文范围（更多相关内容请参阅The Hitchhiker's Guide to the Atmosphere（https://marvins-guide.leaflet.pub/3lyqxqbbqkc2p）），但相关的是ATProto如何处理*身份*。它使用**去中心化标识符（DID）**（https://atproto.wiki/en/wiki/reference/identifiers/did）来实现。例如，我的Bluesky手柄是`@jyn.dev`，但我的ATProto DID3（https://jyn.dev/distributed-identity#fn-5）是`did:plc:h2okxbr76w5522tailkxmidq`（https://atproto.at/uri/at://did:plc:h2okxbr76w5522tailkxmidq）。因为两者不同，这使我最初加入Bluesky时能够将手柄从`@jyn.bsky.social`更改为`@jyn.dev`4（https://jyn.dev/distributed-identity#fn-6）。有趣的是，这允许*你*控制你的数据存储位置。ATProto有一个**个人数据服务器（PDS）**的概念（https://atproto.wiki/en/wiki/reference/core-architecture/pds）：默认情况下，当你加入Bluesky时，你的数据存储在他们的服务器上，但你可以迁移你的PDS并自托管你自己的数据。这意味着，例如，Bluesky无法封禁你；你随时可以迁移到Blacksky（https://blacksky.community/）5（https://jyn.dev/distributed-identity#fn-2）。 好的，那么，让我们把这些结合起来，用在我们的Git身份识别替代方案中。我们现在有了可移植性、可修改性、可撤销性，而且——哦？那是什么？一个一手资料？（https://github.com/did-method-plc/did-method-plc/blob/main/website/spec/v0.1/did-plc.md） > DID操作和更新的完整历史记录，包括时间戳，将永久公开访问。即使在DID停用后也是如此。重要的是要认识到（并告知账户持有人）在alsoKnownAs URI中编码的任何个人身份信息（PII）在DID停用后仍会公开可见，且无法被编辑或清除。在atproto的上下文中，这包括随时间变化的全部手柄更新历史和PDS位置（URL）。明确地说，它不包括任何其他账户元数据，如电子邮件地址或IP地址。手柄历史记录如果用户在已知身份和匿名或假名身份之间切换手柄，可能会使账户持有人去匿名化。 唉……它*需要*以这种方式工作吗？这谈论的是专门针对*bluesky手柄*。但ATProto有许多其他类型的数据（https://atproto.wiki/en/wiki/reference/lexicons）。我们可以就……你懂的。建立我们自己的。带二十一点和妓女。这是一个自定义ATProto记录的示例：（https://atproto.at/uri/at://did:plc:h2okxbr76w5522tailkxmidq/blue.checkmate.game/3msn57l2vrt2x） ```json { "uri": "at://did:plc:h2okxbr76w5522tailkxmidq/blue.checkmate.game/3msn57l2vrt2x", "cid": "bafyreiab3suqph7m5xw2weronkts7ekp224rfrkltwiafluqjff7wtjlsi", "value": { "pgn": "[Event \"checkmate.blue\"]\n[Site \"https://checkmate.blue\"]\n[Date \"2026.08.09\"]\n[Round \"-\"]\n[White \"did:plc:7oyzfpde4xg23u447zkp3b2i\"]\n[Black \"did:plc:h2okxbr76w5522tailkxmidq\"]\n[Result \"1-0\"]\n\n1. e4 e5 2. f4 Nc6 3. Nf3 d6 4. Bc4 Nf6 5. O-O Nxe4 6. Bxf7+ Kxf7 7. Ng5+ Nxg5 8. fxg5+ Kg8 9. Qf3 Nd4 10. Qf7# 1-0", "$type": "blue.checkmate.game", "black": "did:plc:h2okxbr76w5522tailkxmidq", "white": "did:plc:7oyzfpde4xg23u447zkp3b2i", "result": "1-0", "status": "completed", "createdAt": "2026-08-09T08:12:04.842Z", "lastMoveAt": "2026-08-09T08:15:49.540Z", "drawOffered": false, "resultReason": "checkmate", "parentGameUri": "at://did:plc:7oyzfpde4xg23u447zkp3b2i/blue.checkmate.game/3msn4vikzvy2i" } } ``` 这是我与`@notjack.space`在checkmate.blue（https://notes.hadsie.com/3mlbknk2cu22z）上进行的一场国际象棋游戏，这是一个基于ATProto的完全客户端构建的多人国际象棋应用。与`did:plc`记录不同，普通的ATProto记录没有永久历史，可以被删除。 ## 将它们结合起来 https://jyn.dev/distributed-identity#tying-it-all-together 所以，我们修复Bobby问题的一个方法可以是这样的： 1. 就从头构建一个新的VCS数据模型。听着，如果我们把它做成一个jj（https://docs.jj-vcs.dev/latest/）后端，工作量不会*那么*大，对吧？ 2. `.mailmap`保存一个*每个仓库一个唯一的公钥*列表，而不是姓名/邮箱列表6（https://jyn.dev/distributed-identity#fn-4）。 3. 当你创建提交时，不是在元数据中放置姓名/邮箱对，而是嵌入提交的私钥签名。 4. 创建一个新的`org.jyns-awesome-vcs.identity` ATProto模式，其中包含可选的当前姓名和邮箱、可选的历史邮箱、使用OAuth的可选github链接等。嵌入公钥和*每个仓库一个的DID私钥签名*。 5. 当你运行`jj log`时，它会从ATProto获取你的身份。7（https://jyn.dev/distributed-identity#fn-3） 这让我们拥有了所有想要的属性！ - 你可以事后编辑任何身份。 - 你可以在身份记录中添加自定义字段，指示在给定日期之前或之后使用某些姓名。 - 你可以通过从你的ATProto记录中移除DID的签名来删除你的身份。因为签名是每个仓库一个的，删除一个签名不会影响其他签名。 - *不对称密钥对*确保只有你可以声称该DID对应于该提交。可能吧。我不是密码学家。 可以围绕此构建的一种可能的用户界面： 1. Bobby运行`jj git init`，这会给他一个私钥，他将其存入1password。公钥会自动为他设置好。 2. Bobby，可选地，设置提交签名。如果他不设置签名，`jj commit`就只是将公钥嵌入为身份。 3. Bobby访问一个网站，该网站有一个漂亮的GUI设置，用于让他编辑他的身份记录。它无法窃取他的密钥，因为它完全在客户端运行，Bobby可以通过关闭笔记本电脑的Wi-Fi、生成新记录（只有签名，没有密钥）然后重新打开Wi-Fi将其复制粘贴到应用程序的新页面来测试这一点。 Bobby很高兴，因为从他的角度看，他只是像往常一样提交，也许如果他想立即将身份与仓库绑定，只需要多一个`jj identity publish`命令。维护者也很高兴，因为他们永远、永远、永远不需要再考虑提交的GDPR问题了。Bobby的前任对他搬到德国不满意，但那是另一个故事了。 你可以想象将这个想法扩展到提交正文，允许在同样的机制上构建`hg censor`，尽管这更复杂，因为你可能希望它由仓库所有者控制，而不是最初提交更改的人。 现在，这并不能解决*每一个*问题——archive.org确实存在——但它确实解决了“所有别人需要去匿名化你的就是运行`cat .mailmap`”这个问题。 ## 总结 https://jyn.dev/distributed-identity#summary - Git将*所有数据*永久地封存在琥珀中。试图更改它简直是一场噩梦。这对凭据、身份和版权材料都是一个问题。 - `hg censor`善意地尝试解决这个问题，但仅适用于提交内容，不适用于提交元数据。 - 本文提出了一种使用ATProto的分布式身份和自主数据存储，以及一个完全即兴的、未经审查的加密方案8（https://jyn.dev/distributed-identity#fn-7），来解决身份识别（而不仅仅是提交内容）问题。 1. 如果这不成功