Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id CAB9D4B for ; Wed, 28 Oct 2026 18:43:44 +0000 (UTC) Authentication-Results: mx.ietf.org; dkim=pass header.d=blueskyweb.xyz header.s=google header.b=IH7hCMrO; arc=pass ("google.com:s=arc-20260327:i=1"); spf=pass (mx.ietf.org: domain of bryan@blueskyweb.xyz designates 2a00:1450:4864:20::533 as permitted sender) smtp.mailfrom=bryan@blueskyweb.xyz; dmarc=pass (policy=reject) header.from=blueskyweb.xyz Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-6b3dc272dcfso1910343a12.3 for ; Wed, 28 Oct 2026 11:43:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1793213024; cv=none; d=google.com; s=arc-20260327; b=MOyRZUP3h+nFFycph0mpSslBcLVTw0kA4qm9LduSF6tUvMC1MyAennkUrLrSwNZaLI ydebIPB4d7TtpSAU3JbnYTqnhqYgeAy1tStL871FgC4rmN6TW3whepUTV3YNsH+Ayqc8 iWgzF+Ii8gKcS+gK5oNgNhiEJyfhsg0OIISvhURdPoVhbb0SMewryyxmmugtPjBA3LCi +8IFrAfrYYX+H2g8swEZWkxIX25yImTNKniVxPmW22GI64Qso//HJzjTecuRCzVYzhgU AEcaPXNSFHovtHOpRf8LJvon8umAmE9DMi3NEYl+42ml9CFA9MtDEn4F7NOX+o2rI/xg wFcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=Rads7vd9H8rInY15+thOwk/netQeoee8tM4xk3BKHJI=; fh=snw4IpOz3fy0quiub99GzqXDDM477biE60yDYZ95NCE=; b=Qa9Spuje9vV0thNIQ6x9P/P0Gqp67sMnrnVEQurQ67rdXs9Q9V6BOsM9j5dhvE9J62 bfoKxRTF5FKRZobJka/Wf33qklrt6aLIhySZLnzA6cq7nkxzPSiWdo07v7jTmXkBBGSu Ms/PU+Rc6Rtq2i8VFmlTQ2g57Le1EUiMD1rvk7rARWMduVj8rCZSfv0HJFnz5c+JbPZ0 0OHlvmob+7skkPb66btzdSRau/7tj6r/FEVzr2xqJZX7wtGWBCBafT7us3npDQZayjOO /P735sQ3+y0z2FeZbzl+tMWu2ADKWKZUkcjEzSmOMFNtwmgVLThhBPEAD3tPHqBUQctE Ympg==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blueskyweb.xyz; s=google; t=1793213024; x=1793817824; darn=ietf.org; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Rads7vd9H8rInY15+thOwk/netQeoee8tM4xk3BKHJI=; b=IH7hCMrO6ZHXB+QPI3bHEBN5sNangbrq06mcdGV9dp/+3loPK4XOXlb8QtkxGhQR5P OSAzjyJVly4h+7B62PiGVmD/t0yZU2bY5cSlRWkb1AdA//gGXgYU/+zvjDcN65vM7bgc vkhqWvZuFMClLFwzFp8Dpi1NyJoL2+3U8vsqWsNtV3V3OpjegtPw8pLBy8t+ZZeg7FGY 0LNHH1LSES2IBKK1JRddIMVPL9gEcBK+NjMolp6a1JT5xX0PjIYSOmaAbwXIYclv/MZw lPQq4SL6LbDY1U3N+R305rdT4+rls+CFmX9CF8hGRSK70O7Kk5iPsWn0XRT+txiWr/dE 606g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793213024; x=1793817824; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=Rads7vd9H8rInY15+thOwk/netQeoee8tM4xk3BKHJI=; b=EHtDqXrC8QLbOooAh7naXLN5St8oAIVNPWCQ8ixFhY5V44F6plKwzpmDeBSzGmyK+/ 2HbeySgFtRozVis9nw0NcaID7pPG3E+4Z95IUbzbHcYrtkFJeENyOhDZ+I+XExb9Ufvc yMcCYkyxGFyWfxLFEfsvxdZJHPsWldOtQCXnHlFankEa4UA3fOfjetKZxcJgQag2cfJU 5Oi948KAv+S8F05tXig7h1LBfa16SvkPpTU1Y5bIwU1JkTCw/A94N/e3mJ7O5SxQHVWs zdPLlTzdN3BczkDcPoehacZCeXJgNhDzE0XvKRclsFrJ19AYFtglloc/QpAj3fQ8V5P3 C3/w== X-Gm-Message-State: AFq9FYJc2C6HDMHqCqs/AXakrQqwt3jas3JDm5wv327438oUMh2g+fSq 4dIcnLTNaQwcMR9RlXWnI6MIUWt6j/rN3ne04T5dxHi6gHWN+zZJE1qhrW3n6MPlhIOYU54aEKc 6Hqe1eu+mDLiJ8RCqufGgQDjIofZhTRnOZHAJCBZJ X-Gm-Gg: AYBFou0W6GSgcUfB4a4I+bSEQVP0LWeFU93x+y9j6TZaam55IvyY/rWY7Vva2frJQdx 1zHhMNBs0H/vGXjeoQ0exE8ZjKYSnLN9RyCXvGSKJ8knpJJwH59dm1UKu4McCknXBCJlxEjNsoT ss5olgo1tydwevZzb+dcj58Acw6zxCx6OX0AubBycQar+85dz7QjrLXpYgNddKrRwlfaRbxV2cp MhvC6K4tEpF6T/f2nXALDz2PeKrD7g95Tnhng2WRz+CqMhq+k/yMCSAvEBKzxxMguQk17fmSasQ fArXZC3sTIKqY/z97Va3AjFRXKbuYy18o43zC9OeG4f8/bM/IHiQoDB7rep494D5uXl5GJaprEJ nRGGHPfYggg0cPkoFf7Y2qVEXPqgVMOssoV1B/JAVuvuFuooLWfW6baxtyt+i5UkiAKr78cztoe 9XJjKQbvGUlvYPgesuE9EOcqomVtqzhk1NUabINvWVmwErOQ== X-Received: by 2002:a05:6402:52:b0:6b3:baae:fd29 with SMTP id 4fb4d7f45d1cf-6b49cbec299mr1727087a12.23.1793213023536; Wed, 28 Oct 2026 11:43:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bryan Newbold Date: Wed, 28 Oct 2026 11:43:31 -0700 X-Gm-Features: AclHuK_7yv9QDaJw836BeDoIBWzLFVxJ52yWDb1blip5WuBwv_9lSd5PBgHPaYc Message-ID: To: "Emelia S." Content-Type: multipart/alternative; boundary="000000000000465919065eeaf144" X-Spamd-Bar: --------------------------- Message-ID-Hash: E7JEYXZEPGYZ5EWLAZ6YNXCPUTDEXWL3 X-Message-ID-Hash: E7JEYXZEPGYZ5EWLAZ6YNXCPUTDEXWL3 X-MailFrom: bryan@blueskyweb.xyz X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: ATP IETF Mailing List X-Mailman-Version: 3.3.10 Precedence: list Subject: [Atp] Re: Potential 'at' URI Solution List-Id: Authenticated Transfer Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000465919065eeaf144 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Emelia S. wrote: > Also, there's a reason not to use at:space// =E2=80=94 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/') > =3D> parses correctly to: at:/did:plc:735r43lcgemuv2woqpvx3lso/ > my.bulletin.post/3mtiiz6ci6c2j > > So I think that'd be a strong argument against at:space/ > > =E2=80=94 Emelia > > On 28 Oct 2026, at 18:40, Emelia S. 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:/// 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:/// > > And then we could define the `space` reserved word via an extension, whic= h > could then define it's own path segments: > > > at://space///// > > I'm not sure why we'd explicitly need two different URI schemes? > > (The at:// syntax is a valid URI, it's just at:// > that fails due to custom schemes / syntax) > > =E2=80=94 Emelia > > On 28 Oct 2026, at 18:12, Bryan Newbold 40blueskyweb.xyz@dmarc.ietf.org> wrote: > > The 'at:space' example had a typo (the '/space/' was accidentally include= d > 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=E2=80=AFAM Bryan Newbold > wrote: > >> I have a new 'at' URI scheme syntax/structure proposal that could be a >> way forward: >> >> at:public/// >> at:public/did:plc:vwzwgnygau7ed7b7wt5ux7y2/ >> app.bsky.feed.post/3k5nobkf2w72g >> >> As a reminder, the current 'at:///...' syntax with double >> slashes is not a valid IETF URI, nor a valid WHATWG URL. In this proposa= l >> we lose the nice idiomatic prefix ('at://'), but keep the account >> identifiers vebatim, and don't need any escaping or encoding. The genera= l >> 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 th= e >> scope of this group's current charter, but assuming all goes well with t= he >> current charter we expect to propose it in a future re-charter. Spaces h= ave >> 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///// >> >> at://did:plc:735r43lcgemuv2woqpvx3lso/space/my.bulletin.board/self/did:p= lc:735r43lcgemuv2woqpvx3lso/ >> my.bulletin.post/3mtiiz6ci6c2j >> >> This reuses the 'at:' scheme (which we like), but has all the same synta= x >> problems as the current public protocol references (aka, the double-slas= h), >> and also has the '/space/' in the middle. Under the new proposed syntax, >> these could be: >> >> >> at:space/////= / >> >> at:space/did:plc:735r43lcgemuv2woqpvx3lso/space/my.bulletin.board/self/d= id: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 th= e >> 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' synta= x >> 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 sa= me >> time as the public data references. >> >> Some questions for the list: >> >> - are there any concerns about this new proposed syntax being a valid an= d >> 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 > > > > --000000000000465919065eeaf144 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To be clear, I think you are talking about relative U= RL handling. That is not something that I know is needed or beneficial in t= he context of atproto. But it is good to flag as additional context.=C2=A0<= /div>

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:

= =C2=A0=C2=A0URL.parse("at:public/did:plc:vwzwgnygau7ed7b7wt5ux7y2/app.bsky.feed.post/3k5nobkf= 2w72g").pathname

I get back:

On Wed, Oct 28, 2026 at 10:52=E2=80=AFAM Emelia S. <emelia=3D<= a href=3D"mailto:40brandedcode.com@dmarc.ietf.org">40brandedcode.com@dmarc.= ietf.org> wrote:
Also, there's a reason not to use at:space/<did>/ = =E2=80=94 WHATWG's URL parser cannot parse / construct it properly:
URL.parse('my.bulletin.post/3mtiiz6ci6c= 2j',=C2=A0'at:space/did:plc:735r43lcgemuv2woqpvx3ls= o/')

Results in `null`, instead of a valid URI. By compariso= n, the form I proposed:

URL.parse('= my.bulletin.post/3mtiiz6ci6c2j',=C2=A0'at:/did:plc:= 735r43lcgemuv2woqpvx3lso/')<= /span>
=3D> parses correct= ly to:=C2=A0at:/did:plc:735r43lcgemuv2woqpvx3lso/my.bulletin.post/3mtiiz6ci= 6c2j

So I think that'd be a strong ar= gument against at:space/<did>

=E2=80=94 Emel= ia

On 28 Oct 2026, at 18:40, E= melia S. <em= elia@brandedcode.com> 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 ho= sted / 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:
<= br>
=C2=A0 at:/<account>/<collection>/<rkey>

And then we could define the `space` reserved word v= ia an extension, which could then define it's own path segments:
<= div>
=C2=A0 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 i= s a valid URI, it's just at://<authority> that fails due to custo= m schemes / syntax)

=E2=80=94 Emelia

On 28 Oct 2026, at 18:12, Bryan Newbol= d <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:

=C2=A0 a= t:space/did:plc:735r43lcgemuv2woqpvx3lso/my.bulletin.board/self/did:plc:735= r43lcgemuv2woqpvx3lso/my.bulletin.post/3mtiiz6ci6c2j

Th= anks 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 tha= t could be a way forward:

=C2=A0 at:public/<account>/<colle= ction>/<rkey>
=C2=A0 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 U= RI, nor a valid WHATWG URL. In this proposal we lose the nice idiomatic pre= fix ('at://'), but keep the account identifiers vebatim, and don= 9;t need any escaping or encoding. The general shape is unchanged: a three-= tuple of {account, type, key}.

This prefix structure would generaliz= e 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 p= ropose it in a future re-charter. Spaces have a dual namespace structure, w= ith two separate three-tuples, and need distinguishable URIs. With feedback= from the developer ecosystem we have iterated on a couple different syntax= es (including a new 'ats:' URI scheme), and currently settled on a = '/space/' as the first path prefix:

=C2=A0 at://<space-ac= count>/space/<space-type>/<skey>/<repo-account>/<co= llection>/<rkey>
=C2=A0 at://did:plc:735r43lcgemuv2woqpvx3lso/s= pace/my.bulletin.board/self/did:plc:735r43lcgemuv2woqpvx3lso/my.bulletin.post/3mti= iz6ci6c2j

This reuses the 'at:' scheme (which we like), = but has all the same syntax problems as the current public protocol referen= ces (aka, the double-slash), and also has the '/space/' in the midd= le. Under the new proposed syntax, these could be:

=C2=A0 at:space/&= lt;space-account>/<space-type>/<skey>/<repo-account>/&= lt;collection>/<rkey>
=C2=A0 at:space/did:plc:735r43lcgemuv2woq= pvx3lso/space/my.bulletin.board/self/did:plc:735r43lcgemuv2woqpvx3lso/my.bulletin.= post/3mtiiz6ci6c2j

The use of 'public' for the prefix fo= r regular atproto records could be debated; maybe 'at:repo' would m= ake 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 c= all them "URIs".

We have a short time window in which we c= ould adopt the 'at:space' syntax for the atproto spaces beta deploy= ment, which we expect to go live soon after IETF 127 ("by the end of N= ovember"). That would sort of hinge on expecting the general pattern t= o 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 t= his 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.<= br>
Some questions for the list:

- are there any concerns about t= his new proposed syntax being a valid and well-formed IETF URI?
- how li= kely 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?
- ar= e there any firm counter-proposals waiting in the wings?
- any strong ae= sthetic or conceptual objections to this new syntax?

--bryan
_______________________________________________
Atp mailing list -- atp@ietf.org
To unsubs= cribe send an email to atp-leave@ietf.org


--000000000000465919065eeaf144--