WebRTC doesn't work for browser control of a lot of IoT type stuff. The really high volume cheapo devices speak things like CoAP or DTLS, and they don't have the horsepower to run something like WebRTC. You'd need a level of control similar to the berkeley socket API to get the browser to speak those protocols.

At the moment, I see a lot of ridiculous stuff like phone apps talking to some cloud instance which tries to jam the packets back through your firewall into your Internet light bulbs. Congratulations, you literally just used thousands of kilometers of fiber and billions of dollars of routing infrastructure to make the world's most expensive how many... light bulb joke.

It sounds like you're describing HumbleNet: https://github.com/HumbleNet/HumbleNet

Last time I checked on WebRTC tutorials and examples was either too old and deprecated, or required the latest Chrome with some flags enabled. The best we have right now for real time streaming is HLS with up to 20 seconds or more delay. We had real time video chat 20 years ago, why can't we have it in the browser today !?

Yes, it seems like a server side complexity issue should be a fixable problem without updating the standards.

I suppose you'll still need to deploy a stun/turn server to deal with the NAT issues unless you're happy with IPv6 only, but that's not really something the standard can fix.

As mentioned in the doc, one of the options is to simplify WebRTC by making some components optional to enable it's better adoption and easier to implement on the back-end as well as on front-end.