4 Apr
2026
4 Apr
'26
3:03 p.m.
On Fri, 30 Jan 2026 at 02:13, Stephen Paul Weber <singpolyma(a)singpolyma.net>
wrote:
I think we have, with "WebTransport" a real
opportunity to specify a
proper
XMPP-native transport mechanism (no extra framing or use case specific
hacks
like WebSocket or BOSH, full normal TLS support possible when implemented
in
a normal client, etc) that happens to also work from browsers (and other
things like transit through HTTP proxies and HTTP reverse proxies... at
least if they support http3 smelling things).
I'm not sure what the "raw" QUIC advantages could be, but I would be
strongly in favour of making this a special case MAY with WebTransport
handshake support as at least a SHOULD level thing.
For all the purposes I need QUIC for (and Marc Blanchet, too), having full
control over congestion control, keep alives, idle timeouts etc is
important. Web Transport doesn't let you tinker in this way.
Also, Web Transport adds the HTTP/3 handshake, which is breaking the 0-RTT
desire.
I think Web Transport might well be great for many cases, but I'm currently
focused on low-bandwidth, high-latency, high-loss networks, so for my
purposes at least I'm only interested in QUIC itself at this stage.
But, solving QUIC should mean that Web Transport is very easy.
Dave.