To gain widespread use in the shortest amount of time, DAAP over HTTP/3
seems to make the most sense. I do not foresee the end user typing dapps://
into their browsers anytime soon, in the near future. Also, I'm not sure if
I have mentioned this to you, (nor do I suspect that this is anything
anyone will approve of), however, in the spirit of full disclosure, I am
leveraging the most current LLM's in tandem to provide me the knowledge to
write these drafts. In a very true sense, this is using AI to defend
against AI. If this is not allowed or frowned upon, then maybe we need to
re-evaluate that logic. But I do believe that I need to make this point
clear. Gentlemen, your thoughts please?
Respectfully,
* Edward R. Aylward II *702.533.9112
On Mon, Jul 14, 2025 at 8:34 AM Ian Swett <iansw...@google.com> wrote:
> 'Media over QUIC <https://datatracker.ietf.org/group/moq/about/>' is a WG
> that is standardizing an application layer optimized for media and other
> types of data that are better suited to publish/subscribe than HTTP/RPC.
>
> MoQ might be of interest to you directly, but I mainly point it out
> because it's intended to either run over raw QUIC or over WebTransport
> (ideally over HTTP/3), which might be an approach worth adopting for your
> use cases?
>
> I'd be happy to provide more thoughts after reading the draft.
>
> Thanks, Ian
>
> On Sat, Jul 12, 2025 at 10:20 PM Lucas Pardue <lu...@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.edw...@gmail.com>
>> wrote:
>>
>> *Subject:* Proposal: Integrating DAAP Functionality into QUIC
>>
>> *To:* quic-cha...@ietf.org
>> *Cc:* quic@ietf.org
>> *From:* Ed Aylward aylward.edw...@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.edw...@gmail.com
>> DAAP GitHub: https://github.com/ELF-GUARD/DAAP/
>> ORCID: 0000-0003-0313-6993
>>
>>
>>
