A short explainer on the history of standardizing internet protocols, + why a feature most of us never see invalidates some (but not all) at:// URIs.
The authority conundrum
Back in 2005, when the IETF standardized URI syntax in RFC 3986, they used the familiar :// pattern to delineate whether a given URI scheme contained an authority or not:
The authority component is preceded by a double slash ("//") and is
terminated by the next slash ("/"), question mark ("?"), or number
sign ("#") character, or by the end of the URI.
authority = [ userinfo "@" ] host [ ":" port ]That option to contact a protocol-specific port on a given host had been so important back in 1994 when standardizing URLs in RFC 1738 that both of these decades-old specs took great pains to ensure that there'd be zero confusion about what a colon meant in that part of URIs.
Many URI schemes have made do without authorities. For example, DIDs themselves include multiple colons, but they don't use the double-slash, which makes them valid URIs:
Other URI schemes went through various gyrations to make sure that the authorities they did use -- although they weren't necessarily internet hosts -- didn't violate that colon rule:
ipfs://{cid}/{path}, where
cid = bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq
ipns://{ipns-name}/{path}, where
ipns-name = dnslink.example.net, or
ipns-name = k51qzi5uqu5dlvj2baxnqndepeb86cbk3ng7n3i46uzyxzyqj2xjonzllnv0v8Indeed, any existing at:// URIs which use DNS handles in the authority slot are perfectly valid URIs, because they don't violate the colon rule.
You see where this is going, right?
Why DIDs can't be authorities
One of the radical innovations of the AT protocol is to use DIDs -- decentralized IDs -- as the authority for all data transferred or referenced using the protocol. The individual who owns the keys to that DID document controls:
which PDS (personal data server) currently stores that data, +
which DNS handle currently best represents their identity.
As authorities go, that's pretty darn brilliant. Yet the one + only place that you can't stick a naked DID inside a URI is as an authority, because it violates the sacred colon placement rule:
at://did:plc:abc123/...As Brian Newbold explained far more thoroughly back in June, any of the following numbers of slashes would have been valid:
at:did:plc:abc123/...
at:/did:plc:abc123/...
at:///did:plc:abc123/...Or, if we're willing to reformat DIDs to hide the colons, any of these would be valid too:
at://did%3Aplc%3Aabc123/...
at://did-plc-abc123/...
at://abc123.plc.did/...Either avoid the double slash or hide the colons, because ne'er the twain shall meet.
The deep irony here
For many decades, we've been adding levels of indirection to internet addressing.
Abstracting the concept of authority + standardizing how resources can be located is IETF's bread + butter. In the period from 1983 (RFCs 882 + 883) to 1987 (RFCs 1034 + 1035), the IETF worked hard to standardize DNS1, so we no longer had to contact specific hosts via their unique IP numbers.
Efforts like this have helped harmonize how each new protocol added works. Whether it was:
the IETF hasn't shied away from tackling the hard work needed to ensure that, where possible, they'd all standardize a common approach to solving shared problems.
Yet in an era where over-centralization of data on hosts run by a handful of authorities has become a massive social problem, what pragmatic advice are we getting from IETF folks who've earned their gray hairs?
Don't even try to add a little parsing logic to the URI spec to help differentiate the ultimate in decentralized authorities -- DIDs -- from ports. Find some protocol-specific workaround or hack for ourselves, rather than come up with a solution for URI authorities that other protocols could (optionally) use too. Sigh.