Hi, does it make sense to have a js-libp2p-webtransport? :grinning:

You’d need a server implementation that supports WebTransport. Currently, Rust doesn’t have QUIC support yet, and Go has QUIC support, but no WebTransport support.

Additionally, WebTransport has exactly the same problem as WebSockets. The server needs a valid TLS certificate for browsers to be able to establish a connection (without throwing an “insecure! insecure!” warning).

I don’t see that much as a problem tbh.

I didn’t even see that as a problem with WebSockets. For my use case I was just going to develop a companion mobile/desktop app that acted as a proxy for establishing outbound TCP connections from the browser (via WebSocket or WebTransport or WebRTC or whatever).

With WebTransport that just makes that process much easier.

I’m not sure I understand what you’re trying to achieve.

If you have a standalone mobile/desktop app, then you’re not restricted by the browser’s security model (and you don’t have to care about CA-signed certificates). But in that case, you are also not restricted by the browser only allowing Web{RTC, Socket, Transport} connections, so you might as well use a raw TCP or QUIC connection.

Also, I don’t understand why WebTransport would be easier than WebSockets. WebTransport is still under active development at the IETF, and therefore support for the protocol (and interoperability between applications!) will be much more limited than using the well-established standard of WebSockets.

Ah yeah, that is a fair point.

And it wouldn’t be a standalone, it’d be a companion, browsers (and network protocols) are very portable, but device applications/programs are not (also, I’m just a web guy :slight_smile: ). The idea is I want browsers to (through the best means possible) be able to make outbound connections via other protocols than HTTP/WS and webRTC.

The easiest way to do that is some companion application that provides an outbound tunnel/proxy to the internet. Maybe “easier” isn’t the right term to use, but more direct, definitely. With this setup, web browsers can effectively do exactly that (make outbound connections with any protocol).

For my use case, I’m trying to make a decentralized email, where users send their own emails and get subdomains from me (with DKIM/SPF setup), and they use IPFS for storage, etc… All the service does is listen when users aren’t online and store their messages in IPFS encrypted with their public key or whatever, something like that.