Websocket libp2p transport #314
Comments
|
I think we could consider it, but so far celestia-node doesn't listen for websocket by default |
|
Yes, great point. Ideally this would be coordinated with the Go client (although perhaps not strictly necessary?) I will raise this with the Celestia team 🙏 |
|
@lzrscg, Celestia Node team follows this :) We could add WebSocket support, but I would go directly to WebRTC. The diagram says that the Golang side is in the It needs to be enabled anyway, so warrants opening an issue. |
|
Hey @Wondertan! I missed this message and went ahead with creating an issue in the celestia-node repo xD feel free to close it of course I like the sound of WebRTC. But I am concerned that it cannot be run inside a Web Worker: This may be outdated and there may be some workarounds, but being able to easily run a node in a web worker is very important. I will look into this a bit more and get back with better informed thoughts. |
|
I wasn't aware of the workers incompatibility. Yeah that pretty much kills it for us |
|
so it is not listed in WebWorkers available API's (but to note, nor is WebTransport). Comparing WebTransport to RTCPeerConnection, the former has a 'note' on top that it's available in workers and the latter does not. Manual check tho would be the best |
|
WebSocket also has this note |
|
just to note Chrome implementation of WebTransport currently has issues and it would be good to have some fallback transport |
Yeah just confirmed that it is not compatible. index.html <html>
<body>
<div>Hi</div>
<script>
new Worker("./worker.js");
</script>
</body>
</html>worker.js async function startWebRTC() {
const localConnection = new RTCPeerConnection();
const remoteConnection = new RTCPeerConnection();
// Create a data channel on the local connection
const sendChannel = localConnection.createDataChannel("sendChannel");
// Set up handlers for the local connection
sendChannel.onopen = () => {
console.log("Data channel open");
sendChannel.send("Hello, WebRTC!");
};
sendChannel.onclose = () => console.log("Data channel closed");
// Set up handlers for the remote connection
remoteConnection.ondatachannel = (event) => {
const receiveChannel = event.channel;
receiveChannel.onmessage = (event) => {
console.log(`Received message: ${event.data}`);
};
};
// ICE candidate exchange
localConnection.onicecandidate = (event) => {
if (event.candidate) {
remoteConnection.addIceCandidate(event.candidate);
}
};
remoteConnection.onicecandidate = (event) => {
if (event.candidate) {
localConnection.addIceCandidate(event.candidate);
}
};
// Create offer
const offer = await localConnection.createOffer();
await localConnection.setLocalDescription(offer);
await remoteConnection.setRemoteDescription(offer);
// Create answer
const answer = await remoteConnection.createAnswer();
await remoteConnection.setLocalDescription(answer);
await localConnection.setRemoteDescription(answer);
}
// Start the WebRTC connection
startWebRTC();you can run this with the command |
|
Then websocket it is |
|
we've done some digging on this topic recently with @Wondertan. Here's quick summary. Websockets:
WebRTC:
we'll try to see if we can get the reproduction of webrtc error and try to debug it more. To support websockets, we'd likely need to implement support in rust-multiaddress ourselves |
|
Great research and thank you for the update! Here is my take:
I agree this is not ideal, but realistically it seems like this is a good compromise for the browser in cases where webtransport doesn't work. However, I would say, in my humble opinion
is not a good compromise. Some apps might be fine with this, but if we want light nodes embedded everywhere, I don't think this will be suitable :( I personally would not want ship this on the main thread, even with minimal impact Do you see any fundamental issues with requiring nodes that want to accept wss traffic to get a cert? Aside from giving wss browser nodes less peer options? |
no, it will likely be just a very small fraction of the network |
If we decide to ship something like this in |
|
On WebRTC:
On WSS:
Generally, we need to ask libp2p team to add interop tests for both of these scenarios. |
It supports listening and dialing But you will need to handle this yourself in the go-libp2p constructor anyway since |
|
We added a convertion for |
|
We added support for WebSocket in Lumina. It currently works only for Arabica network. We have 2 ongoing issues that still affect iOS support: |
|
The issues were fixed but the restrictions for Safari were not yet removed from lumina.rs front end. For now you can use Chrome in iOS. I'm closing this issue. |
|
Restrictions for Safari are now removed from lumina.rs front end. Note that WebSocket is only deployed in few Arabica nodes for now. |
fl0rek
added this to the Sampling window, javascript APIs and general cleanups milestone
Kudos to the Eiger team for the amazing work here! I'm from Modular Cloud and we want to run light nodes in the browser and on the backend using wasm.
Webtransport is the most performant choice when it is available, but it is not supported in Safari—which affects a large number of users.
Websockets seem like the sweet spot for supporting all platforms. Perhaps it could be added as a fallback option?
Let me know what you think :)
The text was updated successfully, but these errors were encountered: