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. bsky.app/profile/bnewbold.net/…
This matters because as ATproto is pushing for standardization -- datatracker.ietf.org/doc/bofre… -- 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.
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.
The August 2025 release of DietPi v9.16 introduces full support for Debian 13 “Trixie,” initial support for Debian 14 “Forky,” and a wide set of software and system enhancements.
Mini-podcast about an event on this day in working class history.
Our work is only possible because of support from you, our listeners on https://patreon.com/w
Israel declares Gaza City “a dangerous combat zone,” Pakistan floods force evacuation of a million people, UN votes to end Lebanon peacekeeping force dropsitenews.com/p/gaza-city-p…
Xi Jinping, general secretary of the Communist Party of China Central Committee, has called for persistent efforts and long-term mechanisms to implement the guiding principles of the central Party leadership's eight-point decision on improving conduc…
It turns out Nokia’s legendary font makes for a great general user interface font
If you're of a certain age (and not American), there's a specific corporate font you're most likely aware of. You may not know its exact name, and you may not actively remember it, but once you see it, you know exactly what you're looking at. The font's called Nokia Sans (an
Profitez des vidéos et de la musique que vous aimez, mettez en ligne des contenus originaux, et partagez-les avec vos amis, vos proches et le monde entier.
Profitez des vidéos et de la musique que vous aimez, mettez en ligne des contenus originaux, et partagez-les avec vos amis, vos proches et le monde entier.
Profitez des vidéos et de la musique que vous aimez, mettez en ligne des contenus originaux, et partagez-les avec vos amis, vos proches et le monde entier.
Token Design for the Royal Treasury: CRESCENT HOC SYDERE FRUCTUS Studio of Edme Bouchardon (1698 - 1762), French, born Chaumont-en-Bassigny Red chalk and graphite with guidelines in red chalk and graphite on cream antique laid paper, framing lines in red chalk, laid down on cream antique laid paper with blue antique laid paper border adhered to face 1739 harvardartmuseums.org/collecti… #Art #Design #Museum #Gallery #MastodonArt #MastoArt #Culture #Random
@frederikdekker vooral leuk als je een taal leert in een kustplaats waar weinig getij is… Dan spreek je de taal vloeiend en ken je de woorden eb en vloed niet. (Kristiansand kent enkele decimeters tij)
Not to mention that the moon is so massive that it's more like a binary rocky planet than a normal one (and imho the greatest factor in Drake equation/ great filter ideas).
Apple's Xcode 26 beta 7 adds support for GPT-5 and Claude Sonnet 4, which developers can use by signing into their paid Claude account (Chance Miller/9to5Mac)
WIne 10.14 Ships With Updated Mono, VKD3D 1.17 & Ping Support For IPv6
Wine 10.14 is out to end August as the latest bi-weekly development release of this open-source software for enjoying Windows games and applications under Linux and other platforms... phoronix.com/news/Wine-10.14-R…
infinite love ⴳ
in reply to infinite love ⴳ • • •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.
infinite love ⴳ
in reply to infinite love ⴳ • • •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. bsky.app/profile/bnewbold.net/…
infinite love ⴳ
in reply to infinite love ⴳ • • •Authenticated Transfer
datatracker.ietf.orginfinite love ⴳ
in reply to infinite love ⴳ • • •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.
infinite love ⴳ
in reply to infinite love ⴳ • • •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...
infinite love ⴳ
in reply to infinite love ⴳ • • •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**"
Bill, organizer of stuff
in reply to infinite love ⴳ • • •infinite love ⴳ
in reply to infinite love ⴳ • • •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
infinite love ⴳ
in reply to infinite love ⴳ • • •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.
infinite love ⴳ
in reply to infinite love ⴳ • • •And then after that... can you establish equivalence between "trwnh.com between 2014 and 2025" and "a-domain.example after 2026"?
What are the fundamental qualities that identify "me" uniquely regardless of which DNS name I am using?
These are the kinds of questions people need to be asking themselves. Not "is this a name or a location".
/end