Comment by fidotron | Hacker News Reader

Comment by fidotron | Hacker News Reader

This is a core idea I've been thinking about for a while. What I settled on is a system where I have different sensors around which just broadcast (really multicast) a trivial binary encoding of an object (in the JSON sense) whenever they feel like it. The idea is if you standardise the fields in the object then anything listening can decide which messages it wants and which it doesn't.

The problem is inventing or maintaining a standard in this space is going to be a completely thankless task. We've seen things like Android where the theory of Intent interoperability is really good, but in practice it just isn't used that much, or is deliberately broken, such as with Facebook (in order to promote their SDK).

The other problem is that there is a lot of feeling that any standards are being created in the hope that a problem emerges, and it's not like we have any really compelling problems with which to guide the standards. The reality is 90% of the IoT fuss is cloud infrastructure providers trying to come up with a use for their systems, and anything which doesn't rely on them will be told it's not part of the IoT, and is just a traditional hardware effort.

EDIT: started fleshing this out on github a while back ( https://github.com/atomirex/chirp ), but never got round to uploading the actual implementations thanks to their terribly embarrassing state! This might persuade me to get round to resolving that.

Protobuf is not bad, but relies on a fixed schema. Blink protocol transmits the schema and seems much better suited. But then there is the question of message security and authenticity. Hawk encoding seems to be the best option outside of TLS transport.

There are enough existing formats/protocols/standards, let's work with the existing ones and continue to improve them.

My conclusion was obscuring message contents isn't really too important, but certainly authenticating them is, and preventing replay attacks is where it gets hard. (So a challenge/response system would be needed in some cases).

This becomes nasty at the device configuration stage though, since you need to distribute/share keys somewhere. There simply are not protocols around that deal with buying a device from a store, taking it home and magically making it work, but that is the point it needs to get to. The industry seems to be moving towards "solving" that through embedding cellular modems in everything and getting the stuff to phone home.

The actual binary format is beside the point really, but it does need to be as close to self describing as possible.

> There simply are not protocols around that deal with buying a device from a store, taking it home and magically making it work,

There are currently a few such protocols in the works(some still in development, some are starting deployment),highly optimized for the IOT: sigfox, semtech's lora, and the weightless standard.

In general they are low bandwidth, long range protocols(from 1.5 kilometer in dense urban environment to tens of kilometers with direct line of site), mostly use unlicensed bands, use very little power(end user devices might last 5 years on a single battery), enable good latency, and are pretty cheap(around 1 euro per year, maybe less.).

> self describing protocols

It's hard to see that happening on the device side, but having the self-description added on the cloud/router would work.

Reply on news.ycombinator.com