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

[Ryan Barrett <[e-mail]>]

On Tue, Oct 6, 2026 at 3:01 PM Ryan Barrett <[e-mail]> wrote:

>
> 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.
>>
>
Sorry Aaron, maybe I misunderstood you. If you meant that the *ATProto
rotation (and signing) keys* inside the DID doc are the cryptographic
fingerprint, then yes, that's absolutely right, of course, regardless of
DID method.




> 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/
>


-- 
https://snarfed.org/