[Atp] Re: Potential 'at' URI Solution

[Bryan Newbold <[e-mail]>]

To be clear, I think you are talking about relative URL handling. That is
not something that I know is needed or beneficial in the context of
atproto. But it is good to flag as additional context.

Just to make sure there is no confusion for others folks about parsing the
proposed format as absolute web URLs, in my browser, if I call:

  URL.parse("at:public/did:plc:vwzwgnygau7ed7b7wt5ux7y2/
app.bsky.feed.post/3k5nobkf2w72g").pathname

I get back:

  'public/did:plc:vwzwgnygau7ed7b7wt5ux7y2/app.bsky.feed.post/3k5nobkf2w72g'

Which is what I would expect. And the same for 'at:space'.

--bryan

On Wed, Oct 28, 2026 at 10:52 AM Emelia S. <emelia=
[e-mail]> wrote:

> 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
>
> Thanks to Nick Gerakines for the sharp eyes.
>
> --bryan
>
> On Wed, Oct 28, 2026 at 9:47 AM Bryan Newbold <[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
>>
>> 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
>>
>> 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
>>
>> 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] 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]
>
>
>
>