On 28 Oct 2026, = at 18:12, Bryan Newbold <bryan=3D40blueskyweb.xyz@dmarc.ietf.org> = 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:7= 35r43lcgemuv2woqpvx3lso/my.bulletin.post/3mtiiz6ci6c2j

Thanks to Nick Gerakines for the sharp = eyes.

--bryan

On Wed, Oct 28, 2026 at 9:47=E2=80=AFAM Bryan = Newbold <bryan@blueskyweb.xyz> = 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-ac= count>/<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 uri-review@ietf.org 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 -- = atp@ietf.org
To unsubscribe send an email to = atp-leave@ietf.org