Between UPnP, ICE [0], and TURN, haven't we figured this out? I'm asking for real since I've never implemented these. Undoubtedly there are some configurations where these methods fail, but I would expect they work fine on almost all consumer networks.

I understand that TURN is where you proxy the connection through a third-party server, having given up on establishing a direct connection. While that does require a third-party server, there's no reason that server necessarily has to be directly owned/operated by the company; they could set up P2P relays in their devices, and/or open-source the server software so that it could be run locally.

[0] https://tools.ietf.org/html/rfc5245

> In an IPv4 world, with domestic networks connected through NAT and a dynamic IP, external servers are going to remain a thing, because the problem cannot be solved without an external server.

It can be solved, but the setup UX might not be great. Wouldn't you just have an "Advanced" UI that allows you to input the public IP address of your home network? The IoT device itself could take it from there and set up the correct firewall and forwarding rules over UPnP, or you can do it yourself. It's a one-time setup. Despite it being dynamic, how often does your ISP-provided IPV4 address actually change?

> how often does your ISP-provided IPV4 address actually change?

About once a week. This also presupposes that every customer of your home automation gets an external IP address with a router they control. What if you don't? What if you only get an internal or private IP address from your building or whatever?

Well, you can set up Dynamic DNS or (my favorite method) set up a persistent reverse SSH tunnel from the NAT-ed client to a world-facing server.

You're welcome to walk my mother through this process.

What would a venn diagram look like between people like your mother and people that want home automation? My mother is still firmly in the "why would I want an automatic garage door?" category.

I think something like an automatic garage door opener is a reasonable thing for someone to want; same with, for example, a smart HVAC system or potentially security cameras.

It obviously drops off sharply when you start getting into the Bill Gates territory where monitors on the walls adjust their artwork to suit the people currently occupying the room, or modifying the light levels, etc. But all the previously mentioned stuff seems like a reasonable thing to want, the same as an automated washing machine or a microwave oven became standard items.

Perhaps there is a gap in the market for an independent rendezvous service that IoT devices and their controllers can connect to each other over.

Rather than baking in a dependency on the vendor of the specific device not going out of business, not stopping support for the device you bought, and not taking a dislike to you, you could depend upon an independent service that all (or at least many) IoT devices use.

Just run a dynamic dns server and have the client update that. Then in the client software default to using your dns infrastructure but let the user override, so when you go out of business they could set up their own dyndns and use that.

There is still the security problem of course.

You can use Tor Hidden Services to make your home devices accessible from the Internet:

https://github.com/n8fr8/talks/blob/master/onion_things/Inte...

Mesh overlay networks are a thing - you could very well build on them, and provide your own bootstrap hosts. The issue is that there's no incentive to learn how to manage and build that complexity into your devices and apps, vs building a simple web API.

Why do they require a static IP? They should be using DNS. It should be simple for any internet connected device to run dynamic DNS.

Assuming a NAT and restrictive firewall like those included in most consumer routers, DNS gets you the public IP address, but it doesn't get you a port to the client (though one may be better advised to use STUN or ICE). You'd need to punch a hole dynamically with UPnP, require the user to punch the hole manually, or introduce a relay server using something like TURN.

That's assuming you want external access.

Often the user just needs to find the device on their own internal network: in which case a DNS entry of myserialnumber.myIoT.com returning 192.168.1.104 is fine.

Or if you need need to initiate communication from outside the local network: establish a tunnel (in same style as e.g. ngrok).