add the WebTransport effort to the roadmap

[marten-seemann]

My experimentation with WebTransport shows that there are no blockers to getting this implemented an rolled out. In fact, webtransport-go is able to communicate with browser nodes, and we have resolved the peer authentication issue in #404, even avoiding double encryption.

95% of the complexity of getting this implemented is on the Go side, and the remaining 5% on the JS side. If we want to prioritize this effort, the remaining work on the Go side is ~1-2 weeks, and 1-2 days on the JS side.
On the Rust side, this will probably be a lot harder to get going, considering that rust-libp2p doesn't have a QUIC implementation yet, let alone a WebTransport implementation. However, we don't need to implement this in rust-libp2p (for now), we can already reap the benefits of connection js-libp2p to go-libp2p nodes, at least in the IPFS and the Filecoin network.

[mxinden]

👍 for tracking this on the roadmap.

In my opinion we should not prioritize this over "Automated compatibility testing".

[marten-seemann]

In my opinion we should not prioritize this over "Automated compatibility testing".

I wish we were in the position to have better testground testing, but unfortunately that turns out to be a longer-term project. Realistically speaking, we're in the position here to ship a substantial improvement to the connectivity situation in the libp2p network within less than a month, and I don't it would be wise have this effort blocked by our testground effort.

Testing-wise, as undesirable as the current situation is, we still have the go-ipfs transport interop tests, and it should be trivial to add this as another transport test there (assuming that it does run a headless Chromium).

[MarcoPolo]

I think we should prioritize this, especially since there are no blockers and the change would unlock a new whole capability for browsers.

Happy to implement the “5%” js side and help with the Go stuff.

Very exciting!

[mxinden]

I am fine merging here.