I didn't really get it before, but the whole URL vs URN discourse has been a disaster for how people think about network identity. Locations are just names, or rather, everything is a name. What matters is that some names are resolvable canonically and some are only resolvable locally.

Everyone lamenting ties to "network location" or "service provider" is missing the sleight of hand when minting those identifiers. They are minted in the authority of the service provider instead of your own!

A clear path forward is to let people bring their own DNS names to a service provider, and the service provider tracks resources relative to that DNS name as the authority component of an HTTPS identifier.

This is in effect what Bluesky/ATProto is already doing, except they came up with their own scheme for no real reason. You can observe similar breakage when a DNS handle is reassigned to a different DID in much the same way that DNS names can be reassigned to a new IP address.

In the bsky/atproto case, the "sleight of hand" is that you get different identity properties depending on whether you consider the DNS-rooted at:// identifier to be canonical vs the DID-rooted at:// identifier. Whichever one you consider to be the canonical root, that's the one that can't be changed.

The bsky people are expressly discounting the idea that anyone would ever want to move from one DID to another DID -- that kind of "migration" is out of scope to them. https://bsky.app/profile/bnewbold.net/post/3lchpwc2hws2r

This matters because as ATproto is pushing for standardization -- https://datatracker.ietf.org/doc/bofreq-newbold-authenticated-transfer/ -- they are making claims that they can solve a problem that is artificial. Also, their solution does not have the properties they claim it to have. A did:plc identifier is functionally identical to a centralized domain, where everyone uses the same authority component. It's equivalent to using https:// plc.directory to serve HTTP 3xx redirection responses.

If you instead claim the DNS handle is the root of identity, then you might as well use DNS records. Or if you want to use HTTPS, you can use the new CID stuff (Controlled Identifiers) which mirrors the DID work.

The only real barrier to that is that DNS names can change controllership. There's basically a missing time dimension to any request to resolve a name to its records. The entity that controlled ostatus.net in 2015 is not the same entity that controls it in 2025.

This is a similar problem that I've often been irritated by -- *all* identifiers cannot be reliably mapped without considering time!

I have a lot of archived SMS conversations, and typically the viewer of SMS conversations relies on a contact address book to associate phone numbers with names and faces. But much as people pretend otherwise, it is indeed possible to change phone numbers! I have conversations grouped by phone number with messages that were sent by different people over time...

People can change email inboxes too, just like people can change street addresses, just like people can change phone numbers. And just like people can change DNS names. Really, just like any identifier can chnage unless the identity system is immutable (which would come with its own technical and philosophical problems!)

I have wished that VCard or similar could be updated to support specifying time ranges to contact data. "This person has this phone number **from September 2010 to June 2015**"

Have you ever used or known anyone who used a prepaid phone number, or perhaps leased one while visiting a country for some years, and then let it lapse after which point it gets reassigned to someone else? If so, you know what I'm talking about.

DNS names, like any other identifier, are missing the time component that would really solve the issue.

And this is what some DID work attempts to do as well -- a verifiable log of who had which name/key at which time.

But you could do it locally too

The question is, where can you get canonical authoritative data on DNS records over time?

Or alternatively, which contact address book lets you keep track of such data for yourself locally? Which web browser hooks into such an address book?

Say I don't renew trwnh.com past 2025. How can you identify me? "trwnh.com" is no longer enough. You need "trwnh.com between 2014 and 2025" to disambiguate.