jbrMar 10

Who’s using #webtransport in production, in any language?

I’m designing a server api for the trillium ( #rust / #rustlang ) protocol implementation and can’t figure out what sort of higher level abstraction people would want in addition to the protocol-defined interfaces like inbound/outbound x bidi/uni/datagram. Would you want a socket-io-like interface?

Show threadJosh TriplettMar 10
I'm hoping to switch to WebTransport, and have been looking at the Rust wtransport crate and at raw QUIC. Roughly speaking, I'd love for it to look like a thing from which I can spawn channels, in either direction. The biggest reason I want to use it is "WebSocket, but the server can create new connections to the client without a complicated painful callback-like protocol".
Show threadjbrMar 10
@josh Well I've got it working in trillium over h3 now, it's just very low level (AsyncRead/AsyncWrite streams and datagrams). Out of curiosity, what's the motivation for WebTransport instead of QUIC? AFAICT the primary advantage of WebTransport is browser use and/or http-based auth that gates the CONNECT and establishes state?
Show threadJosh TriplettMar 10
The rest of the API is over HTTP already, and does need authentication, and I'd like to avoid recreating concepts like HTTP headers and paths. Not much other than that; it's possible that low-level QUIC may make sense.
Show threadJosh TriplettMar 10
AsyncRead/AsyncWrite streams sound like a delightful API, honestly.
Show threadjbr
@josh https://github.com/trillium-rs/trillium/blob/webtransport/webtransport/examples/webtransport.rs is the current sketch, and by sketch I mean fully functional example
trillium/webtransport/examples/webtransport.rs at webtransport · trillium-rs/trillium

Trillium is a composable toolkit for building internet applications with async rust - trillium-rs/trillium

GitHub
Mar 10 at 9:01pmIvory for Mac