A node in p2p mode should be able to be discoverable without providing it's external IP

The problem

When a customer connects to the p2p network, they shouldn't need to specify their own public IP always. That's a bad UX.

For example, when one starts using a torrent client to download files, they don't need to figure out their public ip in order to get things moving, the torrent client takes care of ensuring the computer is discoverable by the peers and auto adjust.

Current State

As of Nov 2024, when a peer connects to the p2p network, it advertises it's private ip + public ip (if set in the args). These two get's advertised to the network and saved in the dht throught the addressFactory

As a first step to get the nodes from Juno be able to be used as "discover" nodes so people could connect to the network, I've made a first implementation in https://github.com/NethermindEth/juno/pull/2011 by adding a new flag where who ever is running juno could set their own public ip.

I also created a PoC with figuring out what's the public IP of a machine, and advertising it to the peers: See more

How to work on this issue

1. Understand how to advertise the current node's address

• I've tried to setup the EnableAutoRelayWithStaticRelays in the configuration but it still doesn't advertise the relayed address.
  • Maybe the addressFactory is overwriting this configuration somehow

2. Enable relay service

   • Probably the EnableRelayService should still be turned on for the 'bootstrap' nodes (when I tested it was enabled)
   • It might be necessary to update the addressFactory to go throught the list of initial peers (bootstrap nodes) and advertise those IP

3. Figure out how to do proper DCUtR

• Once the connection is made throught the relay, we should try as soon as possible make that connection directly, otherwise the costs for having data being transfered throught the bootstrap nodes will make it expensive to run bootstrap nodes
  • holePunching is already enabled, so it might just work - need testing!
• I'd avise looking at other projects that also use go-libp2p and see how they do. A good example is https://github.com/taubyte/tau and https://github.com/minaprotocol/mina

3. Test with nodes running behind a NAT

• For nodes running behind a NAT, the first step is to try to advertise to the NAT that we want to start listening to a specific port. This should be already enabled here, but it needs testing
• Setup 2 nodes running behind 2 different NAT (for example 2 people from the team running their nodes on their local computers). Start the connection throught the relay, and then see if they will start connecting directly (even though the relay address will still have to be advertised and saved in the dht)

Start with p2p/p2p.go, especially the addressFactory and the EnableAutoRelayWithStaticRelays, EnableRelayService, holePunching, and NAT-port configuration mentioned in the issue. Compare the related PRs and test nodes behind different NATs; done means nodes can be discovered without a configured external IP and can transition from relay connections to direct connections through DCUtR.