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

[Bryan Newbold <[e-mail]>]

Hi Aaron,

Your message covers a lot of ground! I'm going to reply tersely, and
recommend separate mailing list threads for some of these.

On Mon, Oct 5, 2026 at 2:06 PM Aaron Goldman <[e-mail]> wrote:

> However, reviewing the initial batch of drafts, there appears to be a
> tendency to import constraints and assumptions specific to Bluesky’s
> social/microblogging application layer into the foundation of the protocol.
> If we generalize these components, ATP can serve as a much broader Internet
> standard—supporting hierarchical data layout, authenticated distributed
> file systems.
>

I definitely don't want to specify something artificially limited or
over-optimized for the microblogging use-case. I hope that the diverse set
of applications deployed to the current network is at least some testament
to the protocol being more general purpose. If there are simple changes to
make it even more generic, that would be great. The discussion around
floating point numbers in the data model is a good example of that.

However, I also think it is also important to have a defined scope and not
overreach. I'm personally very interested in ways that atproto can
complement or integrate with other network protocols instead of replace
them. The way that Tangled (https://tangled.org) complements git as a
software forge is one example. Maybe we could do the same for distributed
file systems and large-scale network file storage?


> ### Summary of Suggested Changes
>
> 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.

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