Session Date/Time: 05 Nov 2025 14:30

ATP

Summary

This Birds of a Feather (BOF) meeting discussed the Authenticated Transfer Protocol (ATP) and explored whether the IETF is an appropriate venue for its standardization. Proponents presented the protocol's architecture, existing implementations, and various use cases beyond its primary microblogging application. There was broad community interest in the work, with a general sense that the core data structures and synchronization mechanisms of ATP are well-suited for IETF standardization. Discussions highlighted the importance of clearly defining the scope, managing change control, and ensuring the protocol can evolve as a foundational building block for diverse applications.

Key Discussion Points

Problem Statement & Goals: The protocol aims to address issues of centralization, lack of data portability, and limited interoperability in large-scale public broadcast applications by enabling user-owned data, account portability, and separating network identity from location.
Protocol Overview: ATP is a framework of components with self-certifying, content-addressed data (CBOR, Merkle tree, signed). It supports deletion, an abstracted identity layer (DID-based, pluggable), and separates application-specific semantics (e.g., social features) from the core protocol. Data flow involves Personal Data Servers (PDS), Relays, Aggregation Servers, and Clients.
Comparison to Other Protocols: ATP distributes full, primary data (unlike RSS/ActivityPub's metadata). It's a broadcast protocol influenced by P2P technologies (Git, BitTorrent), aiming for a flat, global network topology, distinct from ActivityPub's more "connected islands" model.
Why IETF? The proponents from Blue Sky seek to decentralize control of the protocol, fostering collaborative evolution, dispute resolution, and attracting broader industry participation. They are keen for IETF's expertise in security and evolvability.
Proposed Scope for IETF:
- Core (Green - initial focus): Repository Data Structure (Merkle tree, CBOR, signatures) and Firehose Event Stream (synchronization mechanism, currently WebSocket-based but transport-agnostic).
- Future/Optional (Yellow): The abstracted Identity System and Account Identity/Resolution.
- Out of Scope (Red - not for IETF): Application-specific features (e.g., microblogging, social app semantics, content types, moderation labels, custom feeds).
- The protocol already leverages existing IETF technologies like CBOR, WebSocket, and OAuth.
Ecosystem & Use Cases: Several projects showcased diverse applications of ATP, including Blue Sky (microblogging with custom feeds and moderation labels), Flipboard's SURF (content curation, federated social networking), Tangled (federated social coding blending Git with AT for collaboration), and Black Sky (community-run infrastructure for marginalized communities). Many ecosystem participants expressed strong interest in standardization.
IETF Fit & Expectations:
- The IETF community generally perceived the proposed core work (data transfer, synchronization, formats) as a good fit for IETF's expertise.
- A critical point raised was the need for complete change control transfer if the work moves to the IETF. Proponents indicated willingness to adapt their existing deployments to IETF-driven changes.
- The IETF focuses on creating "building blocks" (Lego pieces) that can be used in radically different architectures, rather than solely maintaining a specific existing architecture.
- The importance of clearly defining abstraction boundaries and the expectations for interoperability across those boundaries was emphasized.
Urgency & Timeline: While proponents do not feel a "dire urgency" to rush to RFCs, they expressed an urgency to establish the IETF as the venue for ongoing discussion and development to build momentum. The process is expected to take several years, akin to other complex IETF protocols like QUIC.
Evolvability: Proponents have successfully iterated on the binary repository format in a live network (currently v3) and believe further changes for IETF are feasible. The separation of sync messages from the transport layer offers flexibility for future adoption of new transports (e.g., MOQ).

Decisions and Action Items

There was a strong sense among those present that the IETF is an appropriate venue for standardizing certain components of the Authenticated Transfer Protocol.
The immediate next step is to continue discussions on the designated mailing list, specifically focusing on the formulation of a charter.

Next Steps

Mailing List Discussion: All interested parties are encouraged to join the non-working group mailing list, [email protected], to continue technical discussions.
Charter Development: The proponents are encouraged to draft charter text for a potential working group and bring it to the mailing list for community review and discussion.
Potential Working Group Formation: Depending on the pace of consensus on the charter, there is a real possibility for a working group-forming BOF at the next IETF meeting (IETF 125) or even for a charter to be approved by the IESG before IETF 125.