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

[Orie <[e-mail]>]

So if most account ids are did:plc today, you could ommit the did:plc:
prefix and insert it when absent, and have well formed URIs.

But that's not desirable because you want to support multiple did methods,
hence the need to url encode account identifiers.

But with the need to support multiple did methods, you now must contend
with the fact that every at uri might be a valid did uri with an at://
prefix... Or it might not be a valid did uri, depending on the method.

I think best solution is to make at:// uris support account identifiers
that are not limited to dids.

And so your resolution logic is not tied exclusively to did url resolvers.

Btw, what media types do these URIs dereference to? Are you sure those
media types are supported by did resolvers for the case where the resolver
supports a given method, and the the at uri is also a valid did url?

What happens if the at uri resolves to content that is different than what
the did url resolves too?



On Tue, Jul 7, 2026, 10:06 PM Jack Grigg <[e-mail]> wrote:

> Hi Orie,
>
> On Wed, 8 Jul 2026, 3:22 am Orie, <[e-mail]> wrote:
>
>> Why is an account identifier needed for at uris?
>>
>> Why can't they just be like ipfs uris?
>>
>
> IPFS URIs work because they are content-addressing, in a very simple way:
> just hash the data. The side-effect of their design is they are completely
> opaque and require a globally-consistent datastore. The need for a globally
> unique cryptographically binding identifier means that the authority part
> of the URI is a long opaque string (the CID), and cannot encode any
> semantics about the data or where to find it. (The URIs support path
> segments, but those navigate *inside* the data; they do not encode info
> about the top-level data).
>
> By contrast, AT URIs leverage and expose the inherent structure of the
> atproto repository, by using the form
> at://account_id/record_type/record_id. This choice to restrict the data
> model from "all possible data" down to "ATProto repo data" has several
> benefits:
>
> - Data now only needs to be unique relative to the account ID, instead of
> globally. In particular, this means that record IDs don't need to be
> generated in a globally unique way; they only need to be unique for a given
> (account_id, record_type) tuple.
> - The account ID can serve multiple purposes: it is the globally-unique
> identifier (but over a much smaller set than "all possible data"), and (by
> the choice to use DIDs) it can also be resolvable to provide a way for
> services to learn *where* data under that account is stored. Tjis greatly
> simplifies the storage model: no need for a DHT or hard dependency on a
> single centralised storage service.
> - A service that observes an AT URI can immediately take actions based on
> its record type (e.g. ignoring all AT URIs that aren't image metadata
> records, or aren'tfrom a specific user). Then when it resolves the URIs it
> does act on, it will validate the data against the record type as usual.
> This can save significant bandwidth by avoiding fetching data you know you
> won't use.
>
> As a side-note, ATProto *does* use IPFS CIDs for "strong references" when
> there is a desire for data to be immutable in a given context. An AT URI
> only says *where* to find a given (semantic) record (like an HTTP URI).
>
> Cheers,
> Jack
>
>
>> On Tue, Jul 7, 2026, 9:07 PM Roscoe Rubin-Rottenberg <[e-mail]>
>> wrote:
>>
>>> The fact that handles aren’t a persistent identifier (people can change
>>> their handle) makes that a non starter. I think either Brian or Daniel
>>> mentioned that they actually think the opposite should be true. Handles
>>> should be disallowed in URIs because it breaks future URIs and isn’t a
>>> persistent identifier.
>>>
>>> On Jul 7, 2026, at 10: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]> 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]>
>>>> 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]> 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]> wrote:
>>>>>
>>>>> On Fri, Jul 3, 2026 at 4:01 AM Ted Hardie <[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%2F
>>>>> app.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]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>> _______________________________________________
>>> Atp mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>>
>>>
>>> _______________________________________________
>> Atp mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>