The tribal knowledge seems to be that you shouldn't do TCP-based hole punching because it's harder than UDP. The author acknowledges this:
> You can do NAT traversal with TCP, but it adds another layer of complexity to an already quite complex problem, and may even require kernel customizations depending on how deep you want to go.
However, I only see marginally added complexity (given the already complex UDP flows). IMO this complexity doesn't justify discarding TCP hole punching altogether. In the article you could replace raw UDP packets to initiate a connection with TCP SYN packets plus support for "simultaneous open" [0].
This is especially true if networks block UDP traffic which is also acknowledged:
> For example, we’ve observed that the UC Berkeley guest Wi-Fi blocks all outbound UDP except for DNS traffic.
My point is that many articles gloss over TCP hole punching with the excuse of being harder than UDP while I would argue that it's almost equally feasible with marginal added complexity.
I had the exact same thought for years but never came around experimenting with it. I also hoped that one could eventually hear that something is off.
I think this can happen by either recognising the "rhythm" in which sounds appear and/or recognising different tones.
As a first step, my idea was to write a logger that plays different beep sounds for different log levels. That way you could mostly identify the “rhythm” because I guess most log messages would have the same severity. However, to a tiny degree also by the pitch of the sound.
Then as a second step I thought of mapping the log message to a scale of sounds by e.g., hashing the message. This obviously would only work if there’s no dynamic content in the message.
It’s just running a very lightweight libp2p host that speaks the DHT protocol. It’s basically just taking the bare minimum part of Kubo (IPFS) that’s necessary to interact with the DHT.
It’s then relying on the rest of the IPFS network to propagate the record for discovering the sender and receiver.
I’m currently working on a new version of pcp [0]. Based on croc, magic-wormhole and the likes it doesn’t require a relay. It uses the IPFS DHT as a discovery point to connect two machines. Haven’t touched the currently released code in two years but the new hole punching capabilities of libp2p show promising result so I’m working on a new version.
It’s gone from the ipfs.io gateway but the CID is still available in the network. Take your own IPFS node (e.g. companion or Brave’s built-in) and you should be able to resolve it
during December 2022, we are running a measurement campaign to investigate decentralized NAT hole punching success rates using the libp2p DCUtR protocol [0]. Ubiquitous peer-to-peer connectivity is still a big challenge. If successful, NAT Hole Punching can be a game-changer for decentralised applications and networks!
For that we are searching for participants who would run a lean client on their machines that performs hole punches with other peers and then reports back the results to our server. We explained the measurement methodology in this video [1] and the linked repository above.
Running such a client certainly has privacy implications which are documented here [2]. Most importantly, we record public IP addresses, successful NAT port mappings, and the login router page (to draw conclusions about which routers work better than others).
Optionally, you can also sign up here [3] and provide additional information about your personal network and receive a personal API key so that we can link your data to your information. Obviously, this has stronger privacy implications - but this is totally optional.
The most frictionless way to participate is to head to the releases page [4] and download a client that suits your platform and needs. No sign-up required.