This certainly was an issue in early days of P2P, but I thought it was already solved for good.
Doesn't P2P works nearly literally everywhere nowadays and aren't there loads of NAT-piercing and/or tunneling libraries that Just Work™? (Well, possibly, unless put behind some truly abysmal corporate firewalls where even plain outgoing HTTP isn't working all the time — but that would be another story.)
Indeed, NAT-piercing isn't new or even revolutionary. It's a small feature of our mission to make building IoT apps as painless and fast as possible.
Our main goal is to build an ecosystem of ready-to-use devices and a RESTful API around this ecosystem so devs can focus on building their awesome IoT application, rather than bothering with the infrastructure. This is a component of that effort.
I don't think NAT piercing works if both of the endpoints are behind NAT, which might happen in this case (e.g. RaspPi + controller app on smartphone).
You could run a server in the middle; but that's exactly what this is.
> I don't think NAT piercing works if both of the endpoints are behind NAT
It does, in many cases even without on any third party. That is a (mostly) solved issue for at least 5 years or maybe even more. Here are examples of such tools: http://samy.pl/chownat/ and http://samy.pl/pwnat/
There are cases such tricks won't work (like overly conscious connection tracking engine and all ICMP traffic blocked - but without ICMP one would have PMTU issues and those ain't fun), but there're always STUN and TURN. The distinction is, those is not middleman, but just a NAT piercing helpers. They don't pass your traffic through and they're generic and useable with any service.
Doesn't P2P works nearly literally everywhere nowadays and aren't there loads of NAT-piercing and/or tunneling libraries that Just Work™? (Well, possibly, unless put behind some truly abysmal corporate firewalls where even plain outgoing HTTP isn't working all the time — but that would be another story.)