DIDs Are Cool. We Didn't Need Them

# DIDs are cool. We didn't need them. Source: [https://www.inamoon.com/blog/dids-vs-subjects](https://www.inamoon.com/blog/dids-vs-subjects) When I first looked at[DIDs](https://www.w3.org/TR/did-core/), they seemed like exactly the right foundation: decentralized, standardized, verifiable identity identifiers\. A quick glance and you can tell: they’re thoughtful, extensible, and in many ways elegant\. I think they’re likely going to live up to the hype, even if it[takes awhile](https://x.com/mankins/status/1560305595512754177)to fully build the bridges to get there\. But for[In a Moon](https://www.inamoon.com/)we kept running into a simpler constraint: we didn’t need a new identity system—we needed a way to use the identity layer already embedded in web content\. DIDs felt heavier than what we needed for this use case\. So we ended up with a much smaller primitive: ``` subject = namespace:id ``` This felt a bit like the classic[XKCD](https://xkcd.com/927/)\.  ## Why we didn’t use DIDs DIDs solve a real problem: portable, self\-sovereign identity\. But for our use case, they introduced friction in the wrong place\. *We didn’t need:* - a new identifier format - a new resolution layer - a new trust framework *We needed:* - something that works with existing web pages - something users already understand - something we can extract without coordination In other words: we needed identity to be*legible*, not*perfect*\. It’s closer to using a regular expression than requiring a full grammar: imperfect, but usable on day one\. Is our implementation perfect? Not even close\! Does it work? Yes\. On day one it’s good, and as we engineer it further we expect to tighten the concepts of parsing, control validation, and namespacing\. ## What are we actually doing? Some[context](https://www.inamoon.com/)helps with this use case: we’re building a system to reward contributions to the web\. Think of it as an “attribution layer” on top of the existing web that enables us to reason about the source for the content\. You can think of it as a very crude implementation of Ted Nelson’s[transclusion idea](https://en.wikipedia.org/wiki/Transclusion)but instead of embedding content, we create an attribution record called a kudos including the creator\. Or if you want to look at it a different way, it’s like a much nicer[ASCAP](https://en.wikipedia.org/wiki/American_Society_of_Composers,_Authors_and_Publishers)for the Web\. > Our main insight is that the web already contains identity embedded in it, and we don’t actually need the adoption of a*new thing*in order for our product to work\. This “Web Identity” layer isn’t formal or canonical—it lives in the vernacular of the web\. It’s the things we already use to identify ourselves and others online: - a GitHub username in a README - a Twitter/X handle in a profile - an email address on a contact page - Youtube, Dribbble, even Hacker News has their own public id system… These are all identifiers\. They’re already in use\. They’re already meaningful as a pointer back to who did the creating\. We don’t need to invent a new identity system to start—we can read the one that’s already there and teach the machines how our namespaces work\. ## A minimal identity primitive to turn Web Identity into something we can use If Web Identities are what you or I would identify when we looked at a webpage: “That’s mankins on BlueSky”, then a`subject`is a namespaced version of this:`bluesky:mankins`\. If a “Web Identity” is what you or I recognize on a page: “that’s mankins on BlueSky”, then a*subject*is just the namespaced version:`bluesky:mankins`\. ### Some more examples of subjects ``` email:[email protected] twitter:jack github:torvalds ``` That’s it\. A`subject`is just a platform/namespace typed identifier: - the namespace tells you how to interpret it - the value is whatever that platform needs\. We don’t require a global resolution protocol to get started—just a consistent way to interpret namespaces\. For us,`hn`is Hacker News\. The coordination for prefix is internal and we can add new namespaces as we need them\. ## From identifiers to identity Of course, a single identifier isn’t enough to identify a*person*\. People have many identities: - multiple emails - multiple social accounts - domains they control - repositories they contribute to So we do our best to record these and verify these ids so a user can verify and control a combined identity\. This is likely a topic for another post, but we do validate ownership via OAuth, DNS, profile proofs, and other methods\. ## Tradeoffs This approach is not as clean as a fully specified identity system\. It’s messy: - platforms can change…Twitter/X is a great example of this\. - we have to maintain a mapping of namespaces to platforms - we have to build custom parsers for each platform to extract the ids But it has one major advantage: it works now, on the web as it exists\. No migration, meta tag, or JavaScript addition required\. ## Currently Supported Namespaces We started with a few namespaces that we know are common and have public identifiers\. We expect to add more as we go, but here are the ones we support today: - BlueSky - Dribbble - Facebook - GitHub - GitLab - HackerNews - Instagram - LinkedIn - Mastodon - Medium - Pinterest - Reddit - Substack - TikTok - Twitch - Twitter/X - Wikipedia - YouTube ## DID Compatibility Of course`did:`is just another namespace\.`did:example:123456789abcdefghi`is both a valid`subject`and`DID`\. We aren’t opposed to them, but just didn’t need them to get started\. ## Try it out All of this is a bit abstract\. If you’re like me you may want to see it in action to see how powerful re\-using existing ids already embedded in web pages is\. Give the[In a Moon extension a try](https://www.inamoon.com/apps)and I think you’ll see how pervasive these ids really are\. [](https://www.inamoon.com/apps)