3 ms·
The really cool part about this is that the server does not need to know the client's ip address. Instead a new original form of ICMP hole punching is used to a
by jgeralnik 7y ago
The really cool part about this is that the server does not need to know the client's ip address. Instead a new original form of ICMP hole punching is used to allow any client to punch the NAT so that the server can dynamically learn the client ip, and then regular UDP hole punching is used.
- mempko 7y agoI'm sad that P2P never took off in the messaging world and now we are stuck with servers storing data even if it's E2E encrypted. I use NAT traversal for Firestr (http://firestr.com http://firestr.com) back in 2013 though this is still cool because of the ICMP hole punching. I'll have to see if I can incorporate that.
- imglorp 7y agoThere's some progress. See https://libp2p.io https://libp2p.io eg.
- toast0 7y agoP2P messaging is a hard sell, in my opinion for a couple of reasons: P2P requires knowledge of the peer's IP, which can be unwelcome depending on the messaging partner (and it's hard to make a config for do you trust this person enough to see your IP: yes, no, only if I'm on network X, not if I'm on network Y, etc) P2P requires both nodes to be online simultaneously, so it's difficult to make work well for asynchronous messaging with smart phones or mobile laptops or desktops that are regularly turned off. Maybe you remember how Skype used to be? So, I think you definitely want a server based store and forward messaging path to ensure delivery and for (optional) privacy from peers, and adding an optional P2P path is additional work, without a lot of gain; at least if it's text. When you start sending media, the bandwidth/storage savings from going P2P make it worth exploring.