當我第一次接觸去中心化識別符（DIDs）時，它們似乎是完美的基礎：去中心化、標準化、可驗證的身份識別符。一眼望去，你會發現它們深思熟慮、可擴展，並且在許多方面都非常優雅。我認為它們很可能會實現人們的期望，即使完全建立起連接的橋樑還需要一些時間。
但對於「In a Moon」來說，我們不斷遇到一個更簡單的限制：我們不需要一個新的身份系統——我們需要一種方法來使用已經嵌入在網頁內容中的身份層。DIDs 對於我們的這個用例來說，感覺比我們需要的要沉重。
所以我們最終採用了一個更小的基本單元：
這感覺有點像經典的 XKCD。
DIDs 解決了一個真正的問題：可攜式、自主主權的身份。但對我們的用例而言，它們在錯誤的地方引入了阻礙。
換句話說：我們需要身份是「可讀的」，而不是「完美的」。
這更像是使用正規表達式，而不是要求完整的語法：不完美，但第一天就可以使用。
我們的實施是完美的嗎？遠非如此！它有效嗎？是的。第一天它就很好，隨著我們進一步的工程開發，我們預計將收緊解析、控制驗證和命名空間的概念。
一些背景有助於理解這個用例：我們正在建立一個獎勵對網頁貢獻的系統。可以將其視為現有網頁之上的「歸屬層」，使我們能夠理解內容的來源。
你可以將其視為 Ted Nelson 的轉錄（transclusion）概念的一種非常粗糙的實現，但我們不是嵌入內容，而是創建一個名為 kudos 的歸屬記錄，其中包含創作者。或者，如果你想從不同的角度來看，它就像一個對網頁來說好得多的 ASCAP。
我們的主要見解是，網頁本身已經包含了身份，而且我們的產品要正常運作，實際上並不需要採用新的東西。
這個「網頁身份」層不是正式的或規範的——它存在於網頁的日常用語中。它是我們已經用來識別自己和他人的東西：
這些都是識別符。它們已經在使用中。它們已經有意義，可以指向創建者。我們一開始不需要發明一個新的身份系統——我們可以讀取已經在那裡的系統，並教機器我們的命名空間如何工作。
如果「網頁身份」是你或我看到網頁時會識別出的東西：「那是 BlueSky 上的 mankins」，那麼一個主體（subject）就是這個的命名空間版本：bluesky:mankins。
如果「網頁身份」是你或我認出的頁面上的東西：「那是 BlueSky 上的 mankins」，那麼一個主體就是這個的命名空間版本：bluesky:mankins。
就是這樣。主體就是一個平台/命名空間類型的識別符：
我們不需要全局解析協議來開始——只需要一種一致的方式來解釋命名空間。對我們來說，hn 是 Hacker News。前綴的協調是內部的，我們可以根據需要添加新的命名空間。
當然，單一識別符不足以識別一個人。人有多個身份：
所以我們盡力記錄這些並驗證這些 ID，以便用戶可以驗證和控制一個組合身份。這很可能是一個關於另一篇文章的主題，但我們確實通過 OAuth、DNS、個人資料證明和其他方法來驗證所有權。
這種方法不像一個完全指定的身份系統那樣乾淨。
但它有一個主要優勢：它現在就可以在現有的網頁上運作。無需遷移、元標籤或 JavaScript 添加。
我們從幾個我們知道常見且具有公開識別符的命名空間開始。我們預計會隨著時間的推移添加更多，但這是我們今天支持的：
當然，did: 只是另一個命名空間。did:example:123456789abcdefghi 既是一個有效的主體，也是一個 DID。我們並不反對它們，只是在開始時不需要它們。
這一切都有點抽象。如果你和我一樣，你可能想親眼看看它是如何運作的，看看重用網頁中已嵌入的現有 ID 有多麼強大。試試「In a Moon」擴展，我認為你會看到這些 ID 實際上有多麼普遍。