[Atp] Re: Opening the AT URI (at://) Syntax Discussion

[Paul Syverson <[e-mail]>]

Hi Bryan and all,

Sorry, topposting and responding to the original message because
I am responding more to the entire thread up to this point rather
than individual messages per se (though I do quote from one of them).

First I would like to voice support for Nick's proposal for lax and
strict syntax. I'm all for trying to move the mountain if that makes
sense in the long run, but I am also in favor of doing things now that
progress the agenda while maximizing compatibility with both existing
practice and existing standards.  It's all trade-offs and compromises,
but this proposal strikes me as the one amongst those Bryan set out in
his blog post and/or were raised on the list that provides such
maximum compatibility.

A few reactions to things that have been said:

On Tue, Jul 07, 2026 at 10:07:33PM -0400, Roscoe Rubin-Rottenberg wrote:
> The fact that handles aren´t a persistent identifier (people can
> change their handle) makes that a non starter. I think either Brian
> or Daniel mentioned that they actually think the opposite should be
> true. Handles should be disallowed in URIs because it breaks future
> URIs and isn´t a persistent identifier.

I find this misleading in a couple of ways. A handle that is a
registered domain can effectively also be a did:web DID (of course not
exactly, which is a major element of this discussion). So, the first
point is that, for most current usage, in this case the handle and the
DID are equally permanent. Indeed, the lack of persistent transparency
here is a motivation for the work on did:webvh. I said "most current
usage" because a did:web DID does not always have to correspond to the
handle in this way. As one example, Nick and I have work that uses a
clearweb URL example.com as handle with a DID, did:web:xyz...123.onion
(more on that below).

The next point is that this (and some other posts) reflects the
perspective primarily of developers (understandably). It overlooks an
important feature of handles: not their impermanence, but their
meaningfulness. Developers and administrators may be mostly using
did:plc syntax, but users much less so. It is a virtue that
https://atproto.com/specs/at-uri-scheme allows both handles and
DIDs as authorities.

https://atproto.com/specs/at-uri-scheme is also misleading. It says,

   A major semantic difference between AT URIs and common URL formats
   like https://, ftp://, or wss:// is that the "authority" part of an
   AT URI does not indicate a network location for the indicated
   resource.

Misleading here is the idea that domain names represent network
locations. That is, at best, only after DNS resolution (which is
subject to lots of issues I will skip so as to not make this post even
longer).

The problem with handles is not so much their impermanence. How and
why links, names, data stores, etc. die matters, PLC DIDs are
reflected in transparent public append-only logs, but we shouldn't
pretend that even PLC DIDs are permanent. If somone in control of the
DID loses/corrupts all copies of all their private keys and then gets
hit by a bus, the DID is a dead as they are. The primary tension is
rather between identifiers that are typically meaningful (e.g. handles
or domain names) and identifiers that are self-authenticating (e.g.,
PLC DIDs or onion addresses). But one can have identifiers that are
both. There are a few ways to do that. Rather than get into it,
I will just note that there is code to bind these together as well
as to check when these are properly bound together and when they are not
https://github.com/ngerakines/domain-attestations

Si sanus es, sanus sum,
Paul

On Thu, Jul 02, 2026 at 12:41:37PM -0700, Bryan Newbold wrote:
> Hi folks,
> 
> I want to kick of a thread to discuss the AT URI syntax, and in particular
> the use of DID syntax (with multiple colons) in the "authority" part of the
> URI. This group is chartered to formalize the "at://" URI scheme in a
> standards-track document. But the currently deployed URIs (with billions of
> strings in the wild) are unfortunately not strictly valid under RFC 3986.
> 
> I recently wrote a blog post about the situation[0]:
> https://bnewbold.leaflet.pub/3mph4hzvbdc2v
> 
> Here is an example URI:  at://did:plc:vwzwgnygau7ed7b7wt5ux7y2/
> app.bsky.feed.post/3k5nobkf2w72g
> 
> Here is the current AT URI syntax specification (which will form the basis
> for a URI scheme I-D) as an informative reference:
> https://atproto.com/specs/at-uri-scheme
> 
> I provisionally registered the "at" URI scheme with IANA back in 2023:
> https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
> 
> One path forward would be to "move the mountain" and try to change the IETF
> URI syntax rules to be more permissive about the "authority" part. This
> would make the current AT URI syntax valid. I assume this would be
> difficult, but could be a positive contribution to the broader internet
> ecosystem in the long run.
> 
> Another path forward would be coming up with a variant syntax or encoding
> which is valid under the current rules. Realistically, the existing syntax
> would need to be supported indefinitely in "legacy" form. For example,
> replacing colons in DIDs with dashes ( at://did-plc-abc123/... ).
> 
> --bryan
> 
> [0]: I'm not sure what the etiquette is, but i'd be happy to copy/paste
> this long-form blog post in to an I-D or on to this mailing list if helpful

> _______________________________________________
> Atp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]