marten-seemann
commented
2 years ago 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
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 https://github.com/libp2p/specs/pull/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.