Hacker News Reader

Comment by pythonaut_16 | Hacker News Reader

What do you think the answer is? Building truly serverless protocols that are content to just live on the WiFi network? That seems like it would require lots of broadcasts on the network which could get congested quickly.

Maybe some kind of standard local server you could run with an easy module API for adding new kinds of devices? Is that what things like Samsung's smart things hub already does?

View on HN

Why would my phone sending commands directly to my lightbulb on the WLAN take up more bandwidth than sending a HTTP request up to the mothership and the lightbulb subscribing to a MQTT channel?

It's not too hard to build distributed server appliances these days. My household is an Apple house, and I have an AppleTV that is a hub for my homekit devices.

It's ridiculous that every webcam, doorbell, etc requires persistent internet connectivity and cloud hosting of whatever. It's a legal risk (I don't want persistent surveillance of my door in the custody of a third party), financial risk (Eero just laid off 40 people, will my wifi work next year?), and general lousy idea imo.

I imagine a device, it could likely run android let's say. That runs "apps" which are really servers - such as philips hues. You interface via your phone/pc?

Consumes would be presented with a QR code on the packaging, and it would take them to the "appstore" for the device

Serverless protocols are ideal, but short of that, just running a local server inside the network is fine.

In principle things like Amazon Alexa or Google Home could serve as that kind of local server, and already have fairly good deployment. But I'd guess their manufacturers aren't likely to be very interested in supporting a non-cloud, local-operation approach.

Reply on news.ycombinator.com