DIDs are cool. We didn't need them.

5 min read Original article ↗

When I first looked at DIDs, 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 to fully build the bridges to get there.

But for In a Moon 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.

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 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 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 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 and I think you’ll see how pervasive these ids really are.