[Atp] Re: Opening the AT URI (at://) Syntax Discussion

[Meredith Espinosa <[e-mail]>]

Operating on handles has been discussed, but is generally not recommended because handles can change while DIDs can't. Being able to change your handle and not break every backlink to your records is one of the major features atproto has over alternative systems.

> On Jul 7, 2026, at 7:03 PM, Orie <[e-mail]> wrote:
> 
> Is it too late to think of at uri as operating on handles? And then rewrite the well-formed uris to whatever is needed for backward compat?
> 
> at://example.com/. <http://example.com/>.. (Actually  a uri) -> at://did: whatever (not a uri)
> 
> Don't attempt to update URIs... And imo don't try to use DID URLs.
> 
> On Tue, Jul 7, 2026, 6:06 AM bumblefudge von CASA <[e-mail] <mailto:[e-mail]>> wrote:
>> Hey Ted:
>> 
>> I was afraid someone would ask.  It's a bit of a mess[^1], tbh, because the suite of changes being proposed was happening across a few interlocking PRs and then one of the editors asked they be withdrawn so he could redo them all in a different order[^2], and now the whole operation of making more expressive DID URLs is at risk[^3] because of W3C timelines.  Of all the mountains this WG could move[^4] in the interest of the having a grown-up version of the ATURI, I would maintain that the DID Resolution spec at W3C is by far the most realistic... it's really just getting a few DID WG members (two of which have already chimed up on this thread) to land something before the normative window closes at W3C.
>> 
>> Thanks,
>> __bf
>> 
>> [^1]: https://github.com/w3c/did-resolution/pulls?q=
>> [^2]: https://github.com/w3c/did-resolution/pull/344
>> [^3]: https://github.com/w3c/did-resolution/pull/346
>> [^4]: https://bnewbold.leaflet.pub/3mph4hzvbdc2v
>> ---
>> bumblefudge
>> janitor @Chain Agnostic Standards Alliance <https://github.com/chainagnostic/CASA>
>> contractable via learningProof UG <https://learningproof.xyz/>
>> mostly berlin-based
>> 
>> On Tuesday, July 7th, 2026 at 12:10 PM, Ted Hardie <[e-mail] <mailto:[e-mail]>> wrote:
>>> Howdy,
>>> 
>>> Can you provide a pointer to the relevant PRs?
>>> 
>>> thanks,
>>> 
>>> Ted
>>> 
>>> On Tue, Jul 7, 2026 at 10:37 AM bumblefudge von CASA <[e-mail] <mailto:[e-mail]>> wrote:
>>>> I would also mention that there is a third option beyond "opening up the syntax" to not being a URI or conforming to the URI spec, in Ted's formulation: just using DID URLs, which were designed for exactly the usecase of a domain-independent URI with a DID as authority and DID-method-specific (but potentially shared across DID methods) mechanisms for paths and query parameters. In recent months, the DID WG has been considering PRs that would make these more expressive and would quite neatly encompass all the current information conveyed in an at://URI...
>>>> 
>>>> ---
>>>> bumblefudge
>>>> janitor @Chain Agnostic Standards Alliance <https://github.com/chainagnostic/CASA>
>>>> contractable via learningProof UG <https://learningproof.xyz/>
>>>> mostly berlin-based
>>>> 
>>>> On Friday, July 3rd, 2026 at 4:55 PM, Stephen Curran <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> On Fri, Jul 3, 2026 at 4:01 AM Ted Hardie <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> > I think you have two choices: define it as an identifier that is not a URI (thus opening up the syntax) or updating the syntax to one that meets the URI specification's requirements. If you take the latter approach, one way to do it might be to adjust it so that the did is not treated as an authority.
>>>>> >
>>>>> > at:did%3Aplc%3Avwzwgnygau7ed7b7wt5ux7y2%2Fapp.bsky.feed.post%2F3k5nobkf2w72g <http://app.bsky.feed.post/3k5nobkf2w72g>
>>>>> 
>>>>> I agree that percent-encoding would be the better (albeit much uglier) way, as just doing a text substitution means that the at: cannot use DID Methods that embed parts of URIs in the DID -- e.g. the current did:web and did;webvh Methods. By definition for those methods, percent-encoding is the only way to embed the DID identifier as proposed as the components allow any valid URI character. There is no character that can just replace the ":"s.
>>>> 
>> 
>> _______________________________________________
>> Atp mailing list -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> _______________________________________________
> Atp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]