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