On Tue, 22 Sept 2026 at 14:14, Florian Schmaus <fschmaus@gmail.com> wrote:
Hi Dave,
Is there a brief summary about what xep467 and yours do differently? And, of the same interest, which things you do in a similar way (if any).
XEP-0467 maps a TCP-like XMLStream onto a single bidirectional QUIC stream. Multiple XMLStreams can be carried in a single QUIC connection as multiple QUIC streams. This preserves nearly all the properties of TCP, for good or bad. The good is that XEP-0198 maps across cleanly, the bad is that Head-of-Line blocking affects the entire XMLStream as a whole, just like in TCP. You do, though, get the advantages of QUIC connection migration between, say, 5G and WiFi. It's a good first step, but it's also a dead end because we can't take advantage of other QUIC capabilities. My approach is to have a single XMLStream map to multiple bidirectional QUIC streams. The specification (but not what I implemented) allows for multiple XMLStreams within a single QUIC connection. This avoids HoL blocking between conversations, reducing the effects of poor networks on the XMLStream as a whole, and meant I needed a different approach for "the ticks" - or at least the first one - since XEP-0198 doesn't work. As such, it uses QUIC itself to provide much of what XEP-0198 does, including the first tick. It also allows us to pipe calls, file transfers, and other non-XMLStream data alongside the XMLStream(s) using other QUIC streams and datagrams, in the future. Or possibly even sending XML elements over datagrams, if we're feeling a bit wild. The similarities are really that both approaches use QUIC, and so we get connection migration, round-trip reductions for connect, and so on. You can (in theory, see other note) connect, negotiate TLS, and do SASL authentication in a single round-trip.
Is there a rendered version somewhere?
No, sadly. Dave.