Re: Proposal: Integrating DAAP Functionality into QUIC

Edward Aylward <aylward.edward@gmail.com> Mon, 14 July 2025 18:04 UTC

MIME-Version: 1.0
References: <CAL6-Gb-dC9OesKtXSYkB4C0U0Zb9A6gm_1gFXdG6uHOfx7RZCw@mail.gmail.com> <CAOYVs2qbqKT8o3xeDn0HMC2sD2TwgSNp-swmMppJE5EJw-oY9w@mail.gmail.com> <11f7334f-56cb-40d2-bf1b-1f1682abb182@app.fastmail.com>
In-Reply-To: <11f7334f-56cb-40d2-bf1b-1f1682abb182@app.fastmail.com>
From: Edward Aylward <aylward.edward@gmail.com>
Date: Mon, 14 Jul 2025 11:03:53 -0700
Message-ID: <CAL6-Gb9xhkvGjcT0tWLb5N71S6Xe_M43adw1hba4QzkD+0JUYA@mail.gmail.com>
Subject: Re: Proposal: Integrating DAAP Functionality into QUIC
To: Lucas Pardue <lucas@lucaspardue.com>
Content-Type: multipart/alternative; boundary="000000000000d6fbba0639e77d1f"
Message-ID-Hash: MXWPE6LZQIHLNR3R53KC3TB62HTJXXPX
CC: Marten Seemann <martenseemann@gmail.com>, QUIC WG Chairs <quic-chairs@ietf.org>, quic@ietf.org
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/rfbF3_IU3a-DdsStsO9BcxLiM-o>

Thank you both for the clarification

          Respectfully,

*          Edward R. Aylward II          *702.533.9112


On Sat, Jul 12, 2025 at 7:19 PM Lucas Pardue <lucas@lucaspardue.com> wrote:

> Hi Edward
>
> On Sat, Jul 12, 2025, at 16:48, Marten Seemann wrote:
>
> It’s difficult to provide meaningful feedback without access to the draft
> itself, but my initial question would be: what’s the justification for
> defining new QUIC frame types? In general, QUIC frames, aside from STREAM
> and DATAGRAM, are intended to modify transport-layer behavior. Based on the
> description, DAAP appears to be an application-layer protocol, and it seems
> more appropriate for it to be layered on top of QUIC rather than extending
> the transport itself.
>
> +1 Marten's points
>
> Generally, embedding non-transport capabilities into the transport layer
> is an anti-pattern. Furthermore, there is no common QUIC API, which makes
> exposing transport features that applications rely on a difficult task.
>
> I'd first encourage you to explore some options for running your protocol
> over HTTP/3 or WebTransport. Both of which run over QUIC and provide clear
> explanations of how QUIC streams or datagrams can be used to exchange
> application protocol data. Then you might get a clearer idea what, if any,
> inefficiences you see.
>
> Cheers
> Lucas
>
>
> On Fri, 11 Jul 2025 at 16:44, Edward Aylward <aylward.edward@gmail.com>
> wrote:
>
> *Subject:* Proposal: Integrating DAAP Functionality into QUIC
>
> *To:* quic-chairs@ietf.org
> *Cc:* quic@ietf.org
> *From:* Ed Aylward aylward.edward@gmail.com
> *Date:* July 11, 2025
>
> ------------------------------
>
> Dear Lucas and Matt,
>
> I hope you’re both doing well.
>
> My name is Ed Aylward, and I’m the author of *draft-aylward-daap-v2*,
> which outlines the Distributed AI Accountability Protocol (DAAP). It’s a
> framework designed to help maintain human oversight over autonomous AI systems
> by requiring regular, verifiable communication with a designated authority.
>
> I’m reaching out to propose a new QUIC extension that would allow DAAP to
> run natively over QUIC. The goal is to move beyond HTTP-over-TCP, embedding
> DAAP’s core functions directly into the transport layer by defining:
>
>    -
>
>    New QUIC frame types for behavioral check-ins, policy updates, and
>    emergency signaling
>    -
>
>    A TLS extension (daap_identity) to establish agent identity at the
>    start of the QUIC handshake
>    -
>
>    Multiplexed streams to handle real-time control, telemetry, and
>    enforcement in parallel
>
> This integration would provide tighter security guarantees, better
> performance, and more responsive control, especially valuable for
> environments where speed, reliability, and accountability are critical.
>
> If the working group is open to reviewing this idea, either as a
> contribution to QUIC or as an individual draft submission, I’d be happy
> to share:
>
>    -
>
>    A working draft in the IETF format
>    -
>
>    Notes on how the implementation maps to current QUIC capabilities
>    -
>
>    Example use cases in sectors like robotics, edge AI, and smart
>    infrastructure
>
> Thanks for considering this. I appreciate your time and would welcome any
> suggestions or guidance on next steps.
>
> Best regards,
> *Edward Richard Aylward, Jr.*
> Email: aylward.edward@gmail.com
> DAAP GitHub: https://github.com/ELF-GUARD/DAAP/
> ORCID: 0000-0003-0313-6993
>
>
>

Proposal: Integrating DAAP Functionality into QUIC Edward Aylward
Re: Proposal: Integrating DAAP Functionality into… Marten Seemann
Re: Proposal: Integrating DAAP Functionality into… Lucas Pardue
Re: Proposal: Integrating DAAP Functionality into… Ian Swett
Re: Proposal: Integrating DAAP Functionality into… Edward Aylward
Re: Proposal: Integrating DAAP Functionality into… Edward Aylward