[Atp] Re: Potential 'at' URI Solution

[Daniel Holmgren <[e-mail]>]

One thing I like about this proposal is that it *isn't* two different URI
schemes. It's all `at:`.

The first path segment (`public` or `space`) is just a semantic of at-uris
not a part of the scheme. To a URI parser it is a scheme (`at:`) followed
by a rootless path.

-- Daniel

On Wed, Oct 28, 2026 at 12:41 PM Emelia S. <emelia=
[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]
>
>
> _______________________________________________
> Atp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>