[Atp] Re: Potential 'at' URI Solution

["Martin J. Dürst" <[e-mail]>]

Dear ATP experts,

I have been following this discussion as an outsider (which I definitely 
am both for ATP as well as for DIDs). [I'm at least moderately familiar 
with URI syntax as one of the authors of the IRI spec (RFC 3987).]

Some comments inline.

On 2026-10-29 07:52, Scott Handley wrote:
> Hi,
> 
> I understand there's little will for improving the current (and aging) URI specification and parsers to adopt a DID in the authority. Nonetheless, I still hold hope that the AT-URI can achieve the same and greater success for innovation that the URI specification has with its flexible path/query/fragment design.

I think it's not so much about the "will". There are so many places URIs 
are implemented, and it's impossible to change them. Over the years, 
every once in a while some protocol has come up with the wish for an 
extension to the syntax, and it was always the protocol that had to give 
way and adapt. And URI syntax is quite adaptable if you look carefully.

> As it stands, the AT-URI specification defines a complementary URI structure with "at://authority [path] [?query] [#fragment]" but the query and fragment are documented as yet to be supported. The allure of the AT-URI has been this intention to conform with the URI specification while delivering its single greatest innovation -- a portable identity (DID) as the “authority”.

I have looked at the syntax of DIDs in 
https://www.w3.org/TR/did/#did-syntax. If this is outdated, please tell 
me. It seems to me that the DID 'inventors' were thinking about DIDs as 
freestanding URIs (registered provisionally at 
https://www.iana.org/assignments/uri-schemes#uri-schemes-1) see also 
https://www.iana.org/assignments/uri-schemes/prov/did. But they didn't 
think about DIDs as authority components in other URI schemes.

Now looking at the syntax at https://www.w3.org/TR/did/#did-syntax, 
there may be a rather easy way to integrate DIDs as authority components 
in general URIs (please excuse if such a solution has been proposed 
already elsewhere).

The 'method-name' component is limited to lower-case letters and digits. 
The 'method-specific-id' is limited to letters, digits, period, hyphen, 
underscore, and colon, with all other letters (if there are any) 
percent-encoded. On the other hand, the host component in the authority 
of an URI, in case it is not an IP address but a reg-name, included 
sub-delims (see https://www.rfc-editor.org/info/rfc3986/#section-3.2.2 
and https://www.rfc-editor.org/info/rfc3986/#appendix-A)

Now sub-delims includes quite a number of characters:
       sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
                   / "*" / "+" / "," / ";" / "="

This does not include ":", but we can replace ":" with one of these. Not 
all of them work equally well visually, and some of them have other 
problems, but instead of e.g.
at://did:plc:735r43lcgemuv2woqpvx3lso, what about
at://did$plc$735r43lcgemuv2woqpvx3lso or
at://did!plc!735r43lcgemuv2woqpvx3lso or so?

That means that if you put a DID into an authority slot, replace the 
colons with "$" or "!" (or whatever other character we choose as most 
suitable). When you take that DID back out, replace the other way round.

And ideally, this wouldn't be decided by ATP for the at: scheme, but in 
coordination with the W3C Decentralized Identifier Working Group and 
potentially other interested parties. It could even go as far as the 
colon in DIDs themselves being changed to another character. DIDs are 
way younger than URIs, and should have an easier job of absorbing such a 
change.

> My concern is that the “at:public” or “at:space” segmentation implies that AT-URI’s can only be one or the other.

I must admit that I don't understand the difference between these two, 
but the long history of networking and data exchange shows that it's a 
bad idea to distinguish between public and (in some way or other) 
private resources so openly in the resource syntax. This is similar to 
other aspects that shouldn't be integrated into identifier syntax. We 
just recently had a proposal for a httpq scheme on the
[e-mail] list (see 
https://mailarchive.ietf.org/arch/browse/uri-review/?qdr=m&q=Scheme%20registration%20request%20-%20HTTPQ) 
This proposed using a different scheme for post-quantum encryption 
protected HTTP resources.

Discussing URI syntax on the [e-mail] list or the 
[e-mail] list may bring up some more ideas.

Regards,   Martin.


> (1) What about content that is local or private or hosted by some current or yet-to-be-invented custom service? Can it have an AT-URI? If no, why not?
> 
> (2) Would additional prefixes be under some form of protocol governance committee? How would such a process expedite/hinder innovation?
> 
> (3) Can the content be referenced such that it starts off in one domain (eg. space) but through its lifecyle ends up in another domain (eg. public)?
> 
> Why further restrict, as opposed to expand, the AT-URI specification with the affordances of the URI specification? What is the hesitation for using the "query" to identify the "service" responsible for "hosting" a resource?
> 
>      Public content =>  at:///did/nsid/rkey?service=atproto
> 
>      Space content =>  at:///did/…?service=atproto_space
> 
>      Other service content =>  at:///did/…?service=acme
> 
> Either one ("/") or three ("///") slashes after "at:" I believe would conform to the URI specification. Here, the query "service” would refer to a service supported by a user’s DID document (either did:plc or did:web)--thereby eliminating the  need to hard-code "at:public ==> service=atproto" and "at:space ==> service=atproto_space". It's also is extensible for future services.
> 
> Just a few thoughts to ponder. I've enjoyed following these conversations in the AT Protocol community...they've been inspirational.
> 
> Best regards,
> 
> Scott Handley
> NorthStar Software LLC
> [e-mail] <mailto:[e-mail]> | www.nstarsoftware.com <https://www.nstarsoftware.com/>
> 
> 
> 
>> On Oct 28, 2026, at 10:12 AM, Bryan Newbold <bryan=[e-mail]> wrote:
>>
>> The 'at:space' example had a typo (the '/space/' was accidentally included in the example). It should read:
>>
>>    at:space/did:plc:735r43lcgemuv2woqpvx3lso/my.bulletin.board/self/did:plc:735r43lcgemuv2woqpvx3lso/my.bulletin.post/3mtiiz6ci6c2j <http://my.bulletin.post/3mtiiz6ci6c2j>
>>
>> Thanks to Nick Gerakines for the sharp eyes.
>>
>> --bryan
>>
>> On Wed, Oct 28, 2026 at 9:47 AM Bryan Newbold <[e-mail] <mailto:[e-mail]>> wrote:
>>> I have a new 'at' URI scheme syntax/structure proposal that could be a way forward:
>>>
>>>    at:public/<account>/<collection>/<rkey>
>>>    at:public/did:plc:vwzwgnygau7ed7b7wt5ux7y2/app.bsky.feed.post/3k5nobkf2w72g <http://app.bsky.feed.post/3k5nobkf2w72g>
>>>
>>> As a reminder, the current 'at://<account>/...' syntax with double slashes is not a valid IETF URI, nor a valid WHATWG URL. In this proposal we lose the nice idiomatic prefix ('at://'), but keep the account identifiers vebatim, and don't need any escaping or encoding. The general shape is unchanged: a three-tuple of {account, type, key}.
>>>
>>> This prefix structure would generalize well to other URIs in the broader atproto ecosystem. For example, design work is wrapping up on "atproto spaces", a protocol extension for non-public data[0]. This is outside the scope of this group's current charter, but assuming all goes well with the current charter we expect to propose it in a future re-charter. Spaces have a dual namespace structure, with two separate three-tuples, and need distinguishable URIs. With feedback from the developer ecosystem we have iterated on a couple different syntaxes (including a new 'ats:' URI scheme), and currently settled on a '/space/' as the first path prefix:
>>>
>>>    at://<space-account>/space/<space-type>/<skey>/<repo-account>/<collection>/<rkey>
>>>    at://did:plc:735r43lcgemuv2woqpvx3lso/space/my.bulletin.board/self/did:plc:735r43lcgemuv2woqpvx3lso/my.bulletin.post/3mtiiz6ci6c2j <http://my.bulletin.post/3mtiiz6ci6c2j>
>>>
>>> This reuses the 'at:' scheme (which we like), but has all the same syntax problems as the current public protocol references (aka, the double-slash), and also has the '/space/' in the middle. Under the new proposed syntax, these could be:
>>>
>>>    at:space/<space-account>/<space-type>/<skey>/<repo-account>/<collection>/<rkey>
>>>    at:space/did:plc:735r43lcgemuv2woqpvx3lso/space/my.bulletin.board/self/did:plc:735r43lcgemuv2woqpvx3lso/my.bulletin.post/3mtiiz6ci6c2j <http://my.bulletin.post/3mtiiz6ci6c2j>
>>>
>>> The use of 'public' for the prefix for regular atproto records could be debated; maybe 'at:repo' would make sense. We would still expect the 'at://' syntax to be supported as a mandatory "legacy" format for all the billions of existing records containing strings in that format, but we would be careful not to call them "URIs".
>>>
>>> We have a short time window in which we could adopt the 'at:space' syntax for the atproto spaces beta deployment, which we expect to go live soon after IETF 127 ("by the end of November"). That would sort of hinge on expecting the general pattern to work out as the public data URI syntax as well. It is impossible to come to a formal consensus on this timeframe, but there is time to get feedback on this list and have a discussion at IETF 127. If there is broad support this format, we will likely use it in the spaces beta deployment. If not, we will likely go ahead with the syntactically-invalid 'at://' format, and resolve that problem at the same time as the public data references.
>>>
>>> Some questions for the list:
>>>
>>> - are there any concerns about this new proposed syntax being a valid and well-formed IETF URI?
>>> - how likely is this new syntax likely to be pass scrutiny at the IESG and/or [e-mail] <mailto:[e-mail]> phase?
>>> - are folks willing to let go of the nice 'at://' prefix?
>>> - is it worth the disruption and friction of supporting two syntaxes ("valid URI" and "legacy non-URI") indefinitely?
>>> - are there any firm counter-proposals waiting in the wings?
>>> - any strong aesthetic or conceptual objections to this new syntax?
>>>
>>> --bryan
>> _______________________________________________
>> Atp mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
> 
> 
> _______________________________________________
> Atp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]