We ended up using the WebRTC data channel to set up communication between our hardware product and mobile app.

There’s still a necessity for a signalling server in between to set up the communication, and a STUN/TURN server to proxy where it’s not possible to set up direct channels. But the whole thing is super low latency and uses DTLS, so it’s a nice alternative for many use cases!

> We ended up using the WebRTC data channel ...

That is an interesting approach. Unfortunately we also have to support browsers so it doesn't look like we could use it. (You have to type in http://something to get the page that does the webrtc as far as I can tell.)

WebRTC can be used a server fashion. We opened a library that does just that: https://blog.rainway.io/real-time-communication-for-everyone...

Unfortunately not applicable. The problem is a user with a regular desktop browser open and has the ip address of the device (on the same subnet). They have to type something into the browser address bar.

As far as I can tell, there is no way they could type something like webrtc://1.2.3.4 and would have to type something beginning with http or https. It can't be the latter because of signing issues, so we are still stuck with http.

More than happy to offer my thoughts if you want to reach out: [email protected]

Couldn't you use it to coordinate NAT punchthrough?

The mobile app (or web browser) are on the same network (subnet) as the hardware device. There is no need for NAT or anything else. Zeroconf is used for discovery.

There is little threat in most home networks, but I still prefer using SSL. If we only had to support the mobile app then we could implement a solution (eg ssh style trust on first use with self signed certificates). However we also have to support regular browsers which constrains us to standard protocols and security.

I'm working on a product that has a similar case - we luckily have the benefit of the hardware having a display and input so that clients need to effectively pair themselves (i.e. you need to physically click an authorized button on the hardware) before they can have full access. We figure that if someone/something has access to the hardware, you're already boned.

We also have a display and also do pairing. You have to press a physical button the device which results in a 4 digit code on the display that has to be entered in the browser or app (somewhat analogous to bluetooth pairing). At the end of the day this results in a cookie being set. But the traffic is still over http.