[Atp] Re: Potential 'at' URI Solution

[Meredith Espinosa <[e-mail]>]

I'm mostly worried that `https://pds.example/xrpc/com.atproto.repo.getRecord?uri=at:///did:web:example.com/app.bsky.feed.post/whatever?service=atproto` or the like would cause issues for URL parsing, since AT URIs are passed through XRPC queries fairly often.

> On Oct 28, 2026, at 4:26 PM, Scott Handley <[e-mail]> wrote:
> 
> Hi Meredith,
> 
> As AT-URIs aren't hyperlinks but are programmatically parsed for DID, NSID, and RKEY in order to form an appropriate XRPC service URL over HTTP, I don't think this is an issue? 
> 
> Have the service as part of the AT-URI would help this programmatic process by identifying the target service in the user's DID document that is responsible for the resource. Today, the public service lookup is hardcoded to "atproto_pds". Presumably, the spaces context would also be hardcoded for lookup. Is there an alternative that could be more open and flexible?
> 
> -Scott
> 
>> On Oct 28, 2026, at 4:12 PM, Meredith Espinosa <[e-mail]> wrote:
>> 
>> Queries are already used by XRPC queries over HTTP, so I don't think they can be feasibly included in URIs as they are right now.
>> 
>>> On Oct 28, 2026, at 3:52 PM, Scott Handley <[e-mail]> 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. 
>>> 
>>> 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”.
>>> 
>>> My concern is that the “at:public” or “at:space” segmentation implies that AT-URI’s can only be one or the other. 
>>> 
>>> (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]
>> 
>