[Atp] Re: Potential 'at' URI Solution

["Emelia S." <[e-mail]>]

Also, there's a reason not to use at:space/<did>/ — WHATWG's URL parser cannot parse / construct it properly:

URL.parse('my.bulletin.post/3mtiiz6ci6c2j', 'at:space/did:plc:735r43lcgemuv2woqpvx3lso/')

Results in `null`, instead of a valid URI. By comparison, the form I proposed:

URL.parse('my.bulletin.post/3mtiiz6ci6c2j', 'at:/did:plc:735r43lcgemuv2woqpvx3lso/')
=> parses correctly to: at:/did:plc:735r43lcgemuv2woqpvx3lso/my.bulletin.post/3mtiiz6ci6c2j

So I think that'd be a strong argument against at:space/<did>

— Emelia

> On 28 Oct 2026, at 18:40, Emelia S. <[e-mail]> wrote:
> 
> Hi all,
> 
> Is there actually really a need for two different URI schemes here? It's all AT Protocol data, all that's changing is where it's hosted / how it's access?
> 
> what's wrong with at:/<account>/<collection>/ where `collection` may either be a reserved word or a valid NSID
> 
> If `collection` is a valid NSID, then the spec defines the further URL segments as:
> 
>   at:/<account>/<collection>/<rkey>
> 
> And then we could define the `space` reserved word via an extension, which could then define it's own path segments:
> 
>   at:/<account>/space/<space-type>/<skey>/<repo-account>/<collection>/<rkey>
> 
> I'm not sure why we'd explicitly need two different URI schemes?
> 
> (The at:/<authority>/ syntax is a valid URI, it's just at://<authority> that fails due to custom schemes / syntax)
> 
> — Emelia
> 
>> On 28 Oct 2026, at 18:12, 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]
>