[Atp] Re: Draft "at" URI Scheme Document (legacy not-actually-URI version)

[Ryan Barrett <[e-mail]>]

Interesting ideas, Aaron! Thanks for writing them up!

Overall, I agree with Bryan. These are valid possibilities for expansion,
but they'd noticeably increase the complexity of the protocol, and the
burden on implementors. ATProto is already an ambitious protocol, and
building a PDS - which these drafts describe the core of - requires a
pretty deep understanding of some nontrivial techniques and structures,
along with a fair amount of work. These generalizations would make that
burden even heavier. I'd be curious to hear more about the user-facing
functionality you have in mind that needs these changes and you think is
worth prioritizing.

Also, one small comment inline...

On Mon, Oct 5, 2026 at 7:18 PM Bryan Newbold <bryan=
[e-mail]> wrote:

> 1. **Clarify Trust Foundations:** Explicitly define the account identifier
>> as a cryptographic fingerprint, and relegate handles to ephemeral,
>> non-authoritative convenience aliases.
>>
>
> I agree that the account identifier is primary, and that handles are
> ephemeral aliases/pointers. If that is unclear anywhere in the current
> draft text, patches are definitely welcome.
>

Re "cryptographic fingerprint": account identifiers are DIDs with one of
two methods, did:plc or did:web. did:plc is cryptographically based, but
did:web isn't.




> Handles are not even in-scope for the current WG charter, and not
> mentioned in the repo sync document. I mentioned them in the aturi document
> because the syntax does get used when declaring handles (as "at://
> handle.example.com" in DID documents), and we need to support them in
> that context.
>
>
>> 2. **Decouple Hosting from Verification & Standardize Ticks:** Clarify
>> that network hosting is a non-exclusive fallback, and introduce signed tick
>> objects for offline/cached freshness proofs.
>>
>
> Agree that account identifier is the real "authority", not the network
> host, and that data could be fetched from other locations and even
> alternative transports/mechanisms. However, I think it is important for
> interoperability for there to be a baseline synchronization mechanism. Is
> there a tension between what you phrased as "fallback" versus "mandatory"?
>
> If I understand the "signed tick" concept, it might be as simple as
> emitting no-op `#commit` events on the firehose, which would increment the
> clock (revision) without changing the repo contents? I think that is
> interesting and worth discussion. There seems like there would be a
> trade-off between time between updates ("how stale") and message overhead
> (rate of commits).
>
> A related topic would be adding cryptographic commitments over some
> `#account` and `#identity` events. Eg, it would be possible for accounts to
> sign messages when the deactivate/reactivate, or when they change some
> identity metadata (like handles). I think it might be hard to cover all
> such events though (eg, account takedowns).
>
>
>> 3. **Generalize Path Depth:** Replace the rigid 2-segment path
>> requirement (`collection/record`) with arbitrary-depth pathing, utilizing
>> prefix-based capability scoping.
>> 4. **Enable In-Repo Chunking:** Standardize lexicographical chunk
>> delimiter semantics (`key:partXXXX`) to support large binary objects
>> directly within repository trees.
>>
>
> These feel like pretty major expansions in scope, and might require
> holistic changes elsewhere in the protocol to support. Probably best to
> discuss in separate mailing list threads?
>
>
>> 5. **Generalize Tree Envelopes:** Abstract the repository tree
>> requirements to accommodate both deterministic MSTs and general Merkle
>> B-Trees.
>>
>
> I think that adding "optionality" in lower-level details like this would
> dramatically increase implementation complexity and be in tension with
> consistent interoperability.
>
> --bryan
> _______________________________________________
> Atp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 
https://snarfed.org/