[Atp] Re: Potential 'at' URI Solution

[Rudy Fraser <[e-mail]>]

I really like being able to immediately tell the difference between the
public and private URIs at a glance when reading left-to-right and during
string parsing.
I think the "at://" prefix inspired ideas about an AT Protocol browser
(like https://)  but that idea seems to have died so personally I'm fine
with letting go of that prefix.

Keeping the legacy not-a-URI format around indefinitely is only mildly
irksome because it breaks the "one obvious way to do things" principle. I
think there was a legacy blob format at one point that was eventually
phased out. My main concern is updating the rsky-syntax (
https://github.com/blacksky-algorithms/rsky/tree/main/rsky-syntax) codebase
to support the v1 format, then reworking the existing code for v0, and
eventually removing the v0 code.

So, being firm about this would be ideal.

On Wed, Oct 28, 2026 at 6:45 PM Daniel Holmgren <daniel=
[e-mail]> wrote:

> 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]
>>
> _______________________________________________
> Atp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 
*Rudy Fraser* *(Pronouns: he/him) *| Founder, Blacksky Algorithms
<https://www.blackskyweb.xyz/> | Fellow, Mozilla | Affiliate, Berkman Klein
Center, Harvard University
Website
<https://blacksky.community/profile/did:plc:w4xbfzo7kqfes5zb7r6qv3rw> •
Linkedin <https://www.linkedin.com/in/rudy-fraser/> • Calendly (book time
with me) <https://calendly.com/rudyfraser>