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 #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
- Understand how to advertise the current node's address
-
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
-
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
- 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)
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 #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
Enable relay service
Figure out how to do proper DCUtR