Streamlining improving the NAT process

The way NAT hole punching is done right now is hard-wired, a .natr and .nat command, and rather inflexible (doesn’t handle internal IPs or help bootstrap independent connections or via a hash instead of IP). The .nat* cmds are also an implicit “relay” of information through a 3rd party, whereas we already have an explicit and well formed process around doing relays, .tap!

Idea to make this much improved is, whenever a switch detects it’s behind a NAT (compare the _to IPs to the IP the OS says you are), it can then .tap any switch that it want’s to get new connections via with it’s own +end and a +pop signal, like such:

{
“.tap”:[{
“is”:{"+end":"asdfasdfasdfasdfasdf"},
“has”:[“+pop”]
}]
}

Now, when any other switch wants to open a line, they send a +end and +pop to the switch that was .tap’d like such:

{
“+end”:“asdfasdfasdfasdfasdf”,
“+pop”:“1.2.3.4:5678”
}

And it gets relayed, where the behind-a-NAT switch can then decide if it wants to send a packet out to that +pop value.

This can work for normal seeding or dialing activity, but it can also work fine for any +end hash and let applications establish direct lines via the exact same +pop signal. Additionally, if the requesting switch determines that both are behind the same NAT, it can send a +pop of it’s internal IP:PORT and establish intranet connections automatically. Another benefit is any switch can +pop open additional ports between each other, that can then be used for RTP, RUDP, etc.

Notes: should that hello packet be empty, so as to not amplify any potential DDoS potential? How much tracking should a switch do to ward off possible flooding?