Received: by mx.ietf.org (Postfix) id 5C3774B for ; Wed, 28 Oct 2026 17:59:51 +0000 (UTC) Authentication-Results: mx.ietf.org; dkim=pass header.d=rudyfraser-com.20260707.gappssmtp.com header.s=20260707 header.b=e9YF2P7g; arc=pass ("google.com:s=arc-20260327:i=1"); spf=pass (mx.ietf.org: domain of him@rudyfraser.com designates 2607:f8b0:4864:20::a33 as permitted sender) smtp.mailfrom=him@rudyfraser.com; dmarc=pass (policy=none) header.from=rudyfraser.com Received: by mail-vk1-xa33.google.com with SMTP id 71dfb90a1353d-5c9e7731b34so961302e0c.2 for ; Wed, 28 Oct 2026 10:58:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1793210318; cv=none; d=google.com; s=arc-20260327; b=E2hICS5FpHFAy//pNe2sE2eTFkPogdei6DiCoE/da756m+kvuau/z+KJFItFuR0PoZ BQPjW+/zgM2Om87khg65jAhh0QKMcs1XqSsmyCfmJJfj/QLF8Q157uXF4CQyMV3QV12b 1uCcAXeMPQXScsdsWv4w3xiY3ORUHlliuto+2SJed3gncO7gGq5E36Qb1tfi9tp4FQKx DD6WK1kQIVjLfD+dc3j86ehx8WjpnynIutVuQuH9hocWg/8B8DRdRP9RgTI0Sw2wKpHK h5SR+SHvYHwnsmZb1chH1RCCHkU8pZrc+TIvziEmzDA5mxwGgpOO9gn8a5zuOOgToNW3 4/mA== 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=1J8AQGos4ksEAcphu7NrWBwiu+YhZ49Y6Lfk9SK+BrY=; fh=vX6VzIuC0zuuLw4yGX0oEwV5rM4rLve4+AKEErHpQV0=; b=cXHas64E8ur3Ezyp+ZoC8whEt6MJcwYuzmtj1ubrJO/Ow9PIYcVHcWZdJ1s9YHzHUt SGXbJlPBxEJack0jroWv2yPXi0jCkMnGLguOTKwKja2aR4cI+2jkLhoWPTePY8Rx3dMc gygGhnRNmeeCKYBBzq/3OVyl/0ahN7/Be+kxht84TiSsgaIWWN61jkLAgP2VzT4CO7Gu eLxhqw2khQv4UoPBvv9YtqIXnfLDatck7e5yDXgkzjmzv0s1FmOc5xJrvaeySg8U4UTt NgmRPQ0725e7yAYwGSdzxD3A/C4uphqP/Nu09WSD2gbjkbOAGRT/c6ZCKe0OSYdX0fLN UOnA==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rudyfraser-com.20260707.gappssmtp.com; s=20260707; t=1793210318; x=1793815118; 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=1J8AQGos4ksEAcphu7NrWBwiu+YhZ49Y6Lfk9SK+BrY=; b=e9YF2P7gSIij6dl1Q16ImEoLlGLjVWl0FhNTxCWgI4K/Y8dQe9INwIVvbJzOeHcsyc q2+E3JsFVvJvsMSQYRTw3kC2NMMCADX9mgVLX/9+v5Rz9eAGdj5FkfWEy2i/1wxiZKg8 /kGyy98EBNO9z6/kmfvOvaq5Sy2JEasuVyaARIxBEU0Iw/WRske7DmaaugoQHAWa0hgf 1gxe0NpI3MseBXTSayV8dJfLV7cF4US5Poiqrd6h9l/yYXE30miZWC38kX4UgS/sE0Bx C/j6DFIwjOaUQ+ksSKBGoExUwzssXNvkUOskBm5QhHynSBruUuxmqDLfhUkpqH1HqQEp wu0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793210318; x=1793815118; 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=1J8AQGos4ksEAcphu7NrWBwiu+YhZ49Y6Lfk9SK+BrY=; b=YY+eo7p93/5YEExqIpExjOyQmzBcfjP7xSpso7ll0Z80HTIBaSylwbTDmZ560iNyyP NxMmmb+LWpCvtMlxMXdfwxK6d3VCTaXM/Wkbn0G0MI9jntnldWgyFP+vwzzIMnqJv79a vacWKwJLWTjBAwDukUHsUTp6Bghv+NmaglR3Fmq27MffwtcsOvrSBAaKiKpB+WuS1Vzk Eok5mmbIPszoONOwB0sFZxai7W25R8lGTjQN+CIhSAJfPqfVRpHLSGe+4I5qhxuTZZ89 g6WX0PCL/oZSdg6VO4TQIDDh3EVtj3A09rmZ+MXJX7OvtTOtYRfwB2LOwJM4JUuEvhLK Pwjw== X-Forwarded-Encrypted: i=1; AKwUvBx1v6v8NaOn1SStof7Kl2gd+lYg7pgeYfxzwPNTBz/yeXJLEPaF1zvluWudawmY5tbNQdc=@ietf.org X-Gm-Message-State: AFq9FYJWbRjvlKB/RgUMnEkuhQJ4bJLy32a69j/71zM1g8pVNR6LfDjx uBBYJwB3AVRr1kT1fk4tZpFz8OAA70XZAMtcQEsHKBhVOO3pFN9t8IoZX9T9ahER1B9fy82XOSN VLVMzK4SaimaKDHmgVFlb26uc6MHdKCH5w2Wl3i0XCA== X-Gm-Gg: AYBFou3UEU/8bAIgHoH80FPe+Kcr2cJ1P2GZFMsJ3Amkj6yB4oX4bvZKwPsO6Bl6H44 lbLhNtQd1rhUO4jzqKkwNVG+y3sr6WI5G4zNtuady9b/XYIGZfaYJ4R4mnyxYP/loSnt21IQSP6 JY2wNHno9I2z01g18wfVACv+3T4S06v7bTr/dCLKi6eTQQI6+RSs9AMEaoytJB7kFUwtev8d8fG F/Xq36qB6vJmpkjsgoEZ7OZ/jpSJ2UvPrTPktOvQwcHnhYcZH5fx3KCKJOhCYWRjlU/LPHUzvMM sLylSznYl9j086YhjPVkaTEpEQy1Z0c5akx2vdIYL59oJ8zraXHNsXx1CI/p+2afFQpQ6Af7PKY WaHoCoCvzsFUS9qPcEvmTv66kxOzIr7RmY34haIT2AJXFMu7wZc2uvxK9iIONmba55ukF5cBJVo AOlRWv1QAtJqgKGsYsStan1A== X-Received: by 2002:a05:6122:428a:b0:5ea:ea07:b119 with SMTP id 71dfb90a1353d-5ec4cc20fc7mr1668860e0c.16.1793210318034; Wed, 28 Oct 2026 10:58:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rudy Fraser Date: Wed, 28 Oct 2026 18:58:25 +0100 X-Gm-Features: AclHuK-REg0x-qk89W2hAi0mpOYlhjjg4w47F8xb1E0WANY7cHzEU9Cpz_2FI44 Message-ID: To: Daniel Holmgren Content-Type: multipart/alternative; boundary="00000000000003aa96065eea50d1" X-Spamd-Bar: ----------------- X-MailFrom: him@rudyfraser.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation Message-ID-Hash: FHZHDQHWFPLUNHWYXYJEXAE7ET6WMIWC X-Message-ID-Hash: FHZHDQHWFPLUNHWYXYJEXAE7ET6WMIWC X-Mailman-Approved-At: Wed, 28 Oct 2026 18:35:53 +0000 CC: Bryan Newbold , 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: --00000000000003aa96065eea50d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Daniel Holmgren 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-uri= s > 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=E2=80=AFPM Emelia S. 40brandedcode.com@dmarc.ietf.org> 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, >> which 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 >> 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=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 propos= al >>> we lose the nice idiomatic prefix ('at://'), but keep the account >>> identifiers vebatim, and don't need any escaping or encoding. The gener= al >>> shape is unchanged: a three-tuple of {account, type, key}. >>> >>> This prefix structure would generalize well to other URIs in the broade= r >>> atproto ecosystem. For example, design work is wrapping up on "atproto >>> spaces", a protocol extension for non-public data[0]. This is outside t= he >>> 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 hav= e >>> 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:= 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////// >>> >>> 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 t= he >>> 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 li= ve >>> soon after IETF 127 ("by the end of November"). That would sort of hing= e 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 IET= F >>> 127. If there is broad support this format, we will likely use it in th= e >>> spaces beta deployment. If not, we will likely go ahead with the >>> syntactically-invalid 'at://' format, and resolve that problem at the s= ame >>> 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 >> >> >> _______________________________________________ >> Atp mailing list -- atp@ietf.org >> To unsubscribe send an email to atp-leave@ietf.org >> > _______________________________________________ > Atp mailing list -- atp@ietf.org > To unsubscribe send an email to atp-leave@ietf.org > --=20 *Rudy Fraser* *(Pronouns: he/him) *| Founder, Blacksky Algorithms | Fellow, Mozilla | Affiliate, Berkman Klein Center, Harvard University Website =E2= =80=A2 Linkedin =E2=80=A2 Calendly (boo= k time with me) --00000000000003aa96065eea50d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I really like being able to immediately tell the diff= erence between the public and private URIs at a glance when reading left-to= -right and during string parsing.
I think the "at://" p= refix inspired ideas about an AT Protocol browser (like https://)=C2=A0 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 f= ormat at one point that was eventually phased out. My main concern is updat= ing the rsky-syntax (https://github.com/blacksky-algorithms/rsky/tree/ma= in/rsky-syntax) codebase to support the v1 format, then reworking the e= xisting 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=E2=80=AFPM Daniel Holmgren <daniel=3D40blueskyweb.xyz@dmarc.ietf.= org> wrote:
One thing I like about this proposal is that it isn&= #39;t=C2=A0two different URI schemes. It's all `at:`.=C2=A0

The first path segment (`public` or `spac= e`) is just a semantic of at-uris not a part of the scheme.=C2=A0To a URI parser it is a scheme (`= at:`) followed by a rootless path.=C2=A0

-- Daniel

On Wed, Oct 28, 2026 at 12:41=E2= =80=AFPM Emelia S. <emelia=3D40brandedcode.com@dmarc.ietf.org> wrote:<= br>
Hi all,
Is there actually really a need for two different URI schem= es here? It's all AT Protocol data, all that's changing is where it= 's hosted / how it's access?

what's wr= ong with at:/<account>/<collection>/ where `collection` may eit= her be a reserved word or a valid NSID

If `collect= ion` is a valid NSID, then the spec defines the further URL segments as:

=C2=A0 at:/<account>/<collection>/<rk= ey>

And then we could define the `space` reserv= ed word via an extension, which could then define it's own path segment= s:

=C2=A0 at:/<account>/space/<space-type= >/<skey>/<repo-account>/<collection>/<rkey>
<= /div>

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)

=E2=80=94 Emelia

On 28 Oct 2026, at 18:12, Bry= an Newbold <bryan=3D40blueskyweb.xyz@dmarc.ietf.org> wrote:

The 'at:space' example had a typo (the '/sp= ace/' was accidentally included in the example). It should read:
=C2=A0 at:space/did:plc:735r43lcgemuv2woqpvx3lso/my.bulletin.board/self/di= d: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 <<= a href=3D"mailto:bryan@blueskyweb.xyz" target=3D"_blank">bryan@blueskyweb.x= yz> wrote:
I have a new 'at' URI scheme syntax/structure pr= oposal that could be a way forward:

=C2=A0 at:public/<account>= /<collection>/<rkey>
=C2=A0 at:public/did:plc:vwzwgnygau7ed7= b7wt5ux7y2/app.bsky.feed.post/3k5nobkf2w72g

As a reminder, the curren= t 'at://<account>/...' syntax with double slashes is not a va= lid IETF URI, nor a valid WHATWG URL. In this proposal we lose the nice idi= omatic 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 exampl= e, design work is wrapping up on "atproto spaces", a protocol ext= ension 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 e= xpect to propose it in a future re-charter. Spaces have a dual namespace st= ructure, with two separate three-tuples, and need distinguishable URIs. Wit= h feedback from the developer ecosystem we have iterated on a couple differ= ent syntaxes (including a new 'ats:' URI scheme), and currently set= tled on a '/space/' as the first path prefix:

=C2=A0 at://&l= t;space-account>/space/<space-type>/<skey>/<repo-account&= gt;/<collection>/<rkey>
=C2=A0 at://did:plc:735r43lcgemuv2wo= qpvx3lso/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 protoc= ol references (aka, the double-slash), and also has the '/space/' i= n the middle. Under the new proposed syntax, these could be:

=C2=A0 = at:space/<space-account>/<space-type>/<skey>/<repo-acc= ount>/<collection>/<rkey>
=C2=A0 at:space/did:plc:735r43l= cgemuv2woqpvx3lso/space/my.bulletin.board/self/did:plc:735r43lcgemuv2woqpvx= 3lso/my= .bulletin.post/3mtiiz6ci6c2j

The use of 'public' for the= prefix for regular atproto records could be debated; maybe 'at:repo= 9; 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 carefu= l not to call them "URIs".

We have a short time window in = which we could adopt the 'at:space' syntax for the atproto spaces b= eta deployment, which we expect to go live soon after IETF 127 ("by th= e 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 impossibl= e 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://&#= 39; format, and resolve that problem at the same time as the public data re= ferences.

Some questions for the list:

- are there any concer= ns 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 an= d/or uri-review@ie= tf.org phase?
- are folks willing to let go of the nice 'at://&#= 39; prefix?
- is it worth the disruption and friction of supporting two = syntaxes ("valid URI" and "legacy non-URI") indefinitel= y?
- are there any firm counter-proposals waiting in the wings?
- any= strong aesthetic or conceptual objections to this new syntax?

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

____= ___________________________________________
Atp mailing list -- atp@i= etf.org
To unsubscribe send an email to atp-leave@ietf.org
_______________________________________________
Atp mailing list -- atp@i= etf.org
To unsubscribe send an email to atp-leave@ietf.org


--
Rudy Fraser=C2=A0(Pronouns: he/him) | Founder, Blacksky Algorithms= | Fellow, Mozilla | Affiliate, Berkman Klein Center, Harvard University
Website=C2=A0<= font color=3D"#203544" face=3D"Open Sans, Helvetica, sans-serif">=E2=80=A2= =C2=A0Linkedin=C2= =A0=E2=80=A2=C2=A0Calendly (book ti= me with me)
--00000000000003aa96065eea50d1--