Hello, welcome to todays NAT 101 class (yes this is Kaspa related - bare with me). Most ppl are familiar with the fact that every device connected to the “internet” has an IP.. What most don’t realise is that in most cases this IP is not a real, globally reachable address. It’s just a local one. Analogy time: someone asks where you live and instead of giving your street address, you say “yeah i’m in the spare bedroom, second door on the left past the laundry”. Completely correct inside your own house, totally useless for anyone trying to navigate to you. That’s basically how home networks work. Your devices have private IPs that only make sense inside your house. The router (the box with flashing lights on it) is the only thing with a real, public address. The reason this exists is simple: 1. We ran out of usable IP addresses (ipv4) ages ago (don’t @ me about ipv6, adoption has been ' coming soon' since 98 lol) 2. Routers act as a basic firewall, so random traffic from the public internet wasteland doesn’t hit your internet connected fridge This process is called NAT (network address translation). It lets all your devices share one public IP, but the tradeoff is: nothing on the outside can start a conversation with you unless you open a port manually (which 99% of ppl never do). (This is where $kas relevancy comes in) so you end up with nodes that can dial out to the network, but the network can’t dial in to them. Lots of home nodes sit in this half connected state. Now, there are ways around this. UPnP is a method that involves the node begging “router pls can i has some open ports?” method, but it’s hit or miss depending on your hardware/security settings (mostly a miss due to poor implementation on home routers or outright blocked as most see it as a security risk). The more interesting method (and the point of this whole ramble) is TCP hole punching. The concept is: two devices behind two different routers want to talk directly, but both routers are blocking inbound traffic (remember, no random traffic to your fridge). So they coordinate through a public “rendezvous server” to make both routers open the right outbound paths. Once both routers see outbound traffic going to the same ip:port, they allow the return traffic too (that’s the hole in the punch). Here’s the flow, simplified: 1. Private node a contacts the rendezvous server (in our case a public node) -> the server learns private node a’s public ip:port 2. Private node b does the same 3. The server gives a the public address of b, and gives b the public address of a 4. A + b both try to open a connection to each other at the same time 5. Those simultaneous outbound attempts cause each routers NAT to create a temporary mapping (ok pass go, collect 200 - NAT is now mildly confused and lets it through) 6. Once those mappings exist on both sides, a handshake can succeed through the two NAT’s and voilla you have connection It doesn’t work for every router or isp setup, but when it does, two private nodes can talk directly without anyone touching router settings. For kaspa, this is huge. if even 50% of private nodes suddenly become fully reachable, the network becomes stronger, more connected, and far more decentralised. There are of course considerations around how we route these connections and how we manage inbound limits. All of that is part of the design work ahead though. Michael started this initiative, and I’m just trying to contribute in whatever ways I can. I’ve put together a PoC that works in a controlled setup, but there’s plenty left to learn and a fair bit to build before it’s ready.