You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
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
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!
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 text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: