Hey all, I'm coming to the end of three weeks of testing XMPP/QUIC over "constrained" networks. The networks here aren't actually particularly bad; but the guest WiFi is horrendous, and I've tested some fairly odd-ball things like running XMPP/QUIC over public 4G data at 5,000ft above one of the great lakes, and an alarming number of people testing this (including the nice people with the network degradation hardware) so I've got a new ProtoXEP. This is a new QUIC binding, with WebTransport support, and is entirely and totally incompatible with the existing Experimental XEP-0467. Obviously Travis paved the way here, and I'm late to the party! https://github.com/xsf/xeps/pull/1561 The first thing I'd like to make clear is that I don't think what I've done is "final" in any sense, but it is a practical starting point for useful discussion. I'm 100% open to changes, and fully expect some in the coming weeks. The second thing is that what I've written is not what I have implemented and tested - it's what I suspect I should really have implemented, in hindsight. I didn't think about the stream headers, for example, which allow multiple stream types, or the refinements about ordering rules I've documented here - I just did bare streams and bare jid pair ordering. It works well, but can be improved. As such, I'd like to propose that - as an experiment in ways of working - Council does not vote on this yet, and we should instead discuss as a community and figure out ourselves when it's ready to put before Council (assuming it ever is). But... The basics of this specification (modulo stream headers) are in Wimsy and my "dwd-deploy" branch of Openfire, and have been heavily tested under a range of network conditions. The basics seem to work well, and effectively cope with some awful traffic conditions. I've been working on this for about 6 months, and for most of that time any messages you've seen from me have gone over QUIC for the C2S leg. Dave.