[Atp] Re: Potential 'at' URI Solution

[Robin Berjon <[e-mail]>]

Hey Bryan,

the primary downside I see with this proposal is that it no longer 
formally has the identity as the authority, despite that being 
conceptually the case. But there are, like, five people who even know 
what an authority is and so in pragmatic terms this is essentially an 
aesthetic bikeshedding concern.

As far as I'm concerned, the requirements for this are:

• It parses.
• It contains the requisite information.

And this meets both. I like clearly separating public from spaced; this 
seems like it could open the door to also flagging different kinds of 
spaces and perhaps at:local.

I don't think that relative resolution is a requirement here. We don't 
have things like resolving blobs relative to other blobs from an AT 
location, for instance — that's what MASL is for.

So I think this works!

This is not a counterproposal but since you seem to have some longing 
for keeping at://, note that these options also work:

#1 Space v public authority

   • at://did:plc:735r43lcgemuv2woqpvx3lso@public/
   • at://did:plc:735r43lcgemuv2woqpvx3lso@space/
   • at://robin.berjon.com@public/
   • at://robin.berjon.com@space/

It's a little clunky to reassemble the identifier but *shrug*.

#2 Special-case DIDs with their own authority

   • at://735r43lcgemuv2woqpvx3lso@plc/
   • at://robin.berjon.com/

This drops the early public/space flag but it has the advantage that it 
keeps existing AT URLs that have a handle authority untouched. The 
semantics remain largely correct. If the authority is a DID method, then 
consult the username. (I never understood what the `did:` prefix was for 
anyway given that any interop only happens at the method level — it 
seems largely spurious?)


On 28/10/2026 17:47, Bryan Newbold 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]

-- 
Robin Berjon (he/him)
https://berjon.com/ - social: https://robin.berjon.com/