As I understand, Dfinity implements some kind of high-end kademlia-based routing mechanism for many things (node discovery, content delivery and so on). Maybe it’s not kademlian, but anyway. For such distributed algorithm to be reliable it is important to enhance it with various NAT traversal techniques. So I assume that every node supports these techniques.
Meanwhile there is a very handy frontend technology called WebRTC used for p2p inbrowser communication. To establish WebRTC connection one needs to implement the same NAT traversal routine (or use some public ICE/TURN server for this) to discover peers’ IP addresses.
Dfinity is very cool, but slow, so no real-time chats and video streaming (on-chain video streaming haha). WebRTC is not so cool, but also secure and very fast - and every fast interaction between users that doesn’t change the state, but delivers information can be performed with it.
So, here is my very convenient question: will the internet computer expose it’s NAT traversal capabilities so others could take advantage of it.
Interesting question. I’m not sure the node comms layer is really going to be exposed to applications like this, but that could be useful couldn’t it. Feature request?
That would be awesome, I think. Client js-library can abstract everything away and create something like more powerful and lightweight web3’s
Sure. How can I issue it?
It should get seen in here actually, these threads are checked by the various teams. You can feel free to send feature requests to email@example.com too.
Is it worth adding a feature request tag @Mike_DFN?
Some networks pursue to be usable from mobile devices through light clients/nodes. The question is, if Dfinity is pursuing to have some state validation on end-user’s devices. But if so, especially for mobile devices, NAT traversal techniques are paramount. If however the only nodes are located in data centers, I assume it to be not so important.
i’m using webrtc datachannels in https://islandcollective.ic.bike and i would also enjoy this feature, if it hasn’t already been done
I have seen nginx referenced in the dfinity docs somewhere, and I’ve also configured nginx on my own signaling server. perhaps this is only a coincidence, but it gave me hope that there is messaging layer already in use that could pass (and potentially validate) the messages involved in the handshake
I was also thinking about this feature from time to time, during all these years.
This could be very handy for any kind of in-browser p2p application: torrents, real-time chats, video streaming, games. It would be great if the platform provided us with a ready-to-use signaling server like that.
Also, since IC is a network scattered across the world, it seems like it could really shine at NAT traversal, allowing a much better WebRTC performance.
Would this make sense as a (potentially opt-in) feature of Boundary Nodes/HTTP Gateways? @raymondk @rbirkner
The other good option I see is using websocket trackers (a la Subins’ P2PT)
I don’t know enough about websockets to say how this would change the network requirements, but it seems like a pretty elegant solution to me
I will try to bring this into the React layer and maybe even as a Unity plugin, so it gets rolled into the asset wasm, or a balance of the two
You raise a good point! It would indeed be great to offer STUN/TURN on the boundary nodes such that dapps can establish WebRTC datachannels without requiring resources outside of the IC.
At the moment, we are focusing on the new boundary node architecture, which is laying the groundwork for features like that. Once we have integrated the new API Boundary Nodes with the NNS and rolled them out, we can start thinking about additional services. This will take some time, but I will keep you updated as we make progress.