What is the current state of internet of things?

First and foremost, the internet of things (or IoT) is a buzzword and an "emerging market" where everyone is scrambling to get a piece of the pie. Secondly, it's nothing new. Before it was called "IoT", it was "M2M" (Machine to Machine), before that it was "Connected Devices", and before that it was "an embedded device that we stuck a POTS modem on". Now that's not to say that there's nothing new going on in the space, with all the flurry of recent activity there is much going on, some good, some bad.

Yes, there really is some good happening. The internet of things as a whole becoming much more prevalent, which in my book is a good thing. People are becoming more aware of the technology and are getting access to devices that make their lives easier, at least in theory. There's also been a great focusing on security, which is going to be extremely important in a future where our homes, offices, shops, and communal spaces are controlled by internet connected devices. This focus on the need for security is coming to light due to real-world security vulnerabilities in real devices, which, fortunately, are still early enough that there is no real dependence on them, so it should be possible to fix these problems before a time when such a vulnerabilities pose threats that are more than just a mild inconvenience.

Unfortunately that's actually entirely true, that is because these security vulnerabilities are in real, working, systems that are in people's homes and could be used to leak information, something as simple as whether someone is home or exposing your wifi network credentials, or they could be used to annoy the users of these devices, flipping their lights on and off or messing with a thermostat, but they could even conceivably be used to break into a house without leaving any evidence that someone, who shouldn't have been, was there.

Those are all very obviously things that will need to be fixed before iot can and even should become something that most people rely on for their everyday needs, but there are a few more issues that you may or may not be thinking about when it comes to the current state of iot.

One issue that is very important and may even be causing problems for the current users of existing iot systems is that of openness and interoperability. The fact that its very much in vogue for creators of current iot devices to create a custom, mostly proprietary, platform for their devices to exist on is rather unfortunate. Sure, many of these platforms will have some form of API or integration with other's platforms, but they are not open platforms and they will never be able to integrate with every other platform out there. This seems to be caused by the fact that most of the players in this space have delusions of grandeur, thinking that they will become the center of all of the future iot ecosystem. Even those that don't think this way have very little incentive to make their platforms open, once they have you as a customer it's almost always in their best interest to coerce you into investing your time and money into configuring and customizing your setup within the walls of their platform as much as is possible.

With the proliferation of all of these various walled gardens it gets harder to make all the devices you buy from various vendors interact with each other. Maybe you want your smart bed cover to work with your smart lights to wake you up naturally at the right time or maybe you just want your smart door lock to tell your entry way lights to turn on when you unlock your front door. unfortunately, with the current model of iot device connectivity you'll probably need to run your own translation service on your own personal server just so that you can receive a notification from one platform's HTTP REST API and translate it to the other platform's MQTT pub-sub API. Even if you're one of the few people that not only understood all of what what that example meant but also understands what is needed to work around these problems and is able to actually do so, the fact is that almost no one actually wants to spend the time managing these custom services that would be required to keep the system functioning and secure. The fact that most of the population of the world doesn't even know what that means should tell you that this isn't a viable position to keep.

The next unfortunate fact is that even if you’re one the few people that’s willing to write and run the custom translators that would be required to run the house of the future that everyone is claiming to sell, It's actually going to be in the best interest of the device creators to shut down their current platforms in favor of creating new ones for every new version they create. That's because, if you're a previous customer of theirs that's happy with their current product and isn't planning to upgrade, shutting down their "old" platform suddenly creates a new potential customer out of you.

All of these various closed platforms that are made to be part of the core functionality of the devices also creates one of the biggest privacy problems with the current version of the internet of things, that is that you have to fully trust the creator of your iot devices both now and in the future. All of your data is running through their servers which means that you're trusting them to not only sell you a properly engineered device but to also keep their word that they won't look at your data, that they won't share it with anyone that will, and that they'll never get hacked and have your data stolen and, most importantly, you’re trusting that none of that will ever happen in the future. This is because all current iot systems, at least that I'm aware of, while they may encrypt you data in transit between your device and their platform, your data is always in plaintext within their platform so that they may act upon it.

With all of these problems, what’s the solution? Well I’m glad I’m assuming you’re asking that. Lets talks about what we need from our new protocol/

Goals

No Third-Party Should be able to Get Your Data or Control your Devices

Your data should only be visible to you and those you want to have access your your data, same goes for controlling any of your devices. This is something that should be cryptographically enforced, not based on what the marketing department some company decided to say.

No Dependence on New and Interesting

I don’t want this whole protocol to flop just because something like z-wave or zigbee ends up dieing, it will depend only on well established technology or small, non-hardware, pieces we can reasonably bring along to any hardware platform.

No Dependence on External Services for Core Functionality

No one wants all of their expensive, shiny, and (still basically) new toys to stop functioning just because some startup ran out of their kickstarter money. Now, that being said, not every feature that people usually want will be available without some third-party services. Things like email, sms, and mobile push notifications can’t be done directly from a local network, but hopefully we’ll be able to find a way to work around most of them, at least enough that most people don’t need them and those that really do will be able to use a variety of third-parties that won’t all go away in a flash.

Local First, Internet Second

Everyone likes the idea of being able to adjust their thermostat from work, but having your lights not turn on when you come home just because your internet has gone down is silly. All actions should happen over the local network when both devices are on the local network.

Ruthlessly Simple

I didn’t really talk much about this above, but many of the protocols that are trying to be the standard for the internet of things are ridiculously complicated and very much smell of ‘design by committee’. This protocol should be able to be explained to someone in the field in under two minutes in a way that they understand most of the protocol.

Built on Existing Open Protocols Wherever Possible

There’s no point in reinventing the wheel in places that already have an acceptable wheel. This project isn’t going to try to create a new parallel internet or replace proven security protocols like TLS and DTLS.

Non-Goals

I feel the need to mention a few of the things I already know I can’t solve, I want to set some realistic expectations.

Perfect Security

Perfect security is not possible. Even having “industry leading” security can cause the system to be so cumbersome and difficult to implement that it’s not the most reasonable path to take.

Perfect Reliability

This is not intended to be a 100% fault tolerant system, if your local network goes down things are probably going to stop working.

Realistic Expectations

This system is probably not going to take over the world. Google is probably never going to implement this protocol in it’s Nest devices. Apple is never going to replace HomeKit with this system. However it is my hope that other Maker/Hacker types will see the value in having a single protocol for the “internet of maker’s things” which doesn’t depend on the goodwill of corporations to continue to work and that some of them will help me with getting this implemented on a few different platforms and programming languages.

What Next?

The guiding goal with the design of Virga is ruthless simplicity while attaining the minimum needed specification or as Albert Einstein probably never said, “Everything should be made as simple as possible, but no simpler.” To take a step back, I should probably answer the question of "What is Virga?"

What is Virga?

I've described Virga as a "system" in various places so far, but to be more specific it's a protocol specification and reference implementation for a fully distributed, cloud-free, internet of things network.

Okay, What Does that Mean?

Most people are familiar with the internet of things in one way or another. Some might view it through the promise of home automation and be looking forward to finally getting to live through the promises that The Jetsons made, while others might have a more cynical view, seeing only the invasions of privacy and near constant news of security vulnerabilities that it has brought so far. My goal with Virga is to make the vision of the first group a possibility while designing a protocol that takes as many precautions as possible to satisfy the worries of the second group.

My vision is for a protocol that is local first, and thus "internet-optional", while being able to be distributed in such a way that it's possible for you and only you to access your home devices from anywhere you have an internet connection without any of your data flowing through any third-party services that want to profit from your personal data.

Additionally, it's a protocol that isn't over specified, but is able to grow and evolve with whatever it ends up being used for. While having a protocol that is completely and totally specified for every thing you want to use it for would be great for zero-config interoperability, it's just not practical and would make for a specification so large that no one would ever be able to fully implement it. It's my opinion that it's better to make the protocol flexible enough that it can be used for almost anything, but specified enough so that any specific configurations are very simple and only needed near the edge where the data is acted upon. This way others can build on it in very simple ways only in the areas that are needed.

My intention, especially in the case of the reference implementation, is to not use new, novel, technology, except in the case of a couple areas that I view as being especially helpful to the end goals, but to use tech that is well established and well understood. I want to use technology that most will already be familiar with and already have available in their homes. To that end everything in the specification will build on top of IP, there won't be any obscure or proprietary protocols connecting the devices. The reference implementation devices will all connect using WiFi or ethernet since those will be available in any house that is likely to want any of these types of devices. The hardware used will be on things that are familiar to the users of Hackaday, Raspberry Pi's running Linux and ESP8266's running Arduino.

Again, the goal is to be simple and flexible.

Okay, so When Can I See Something?

The full implementation is going to span the whole of the Hackaday Prize 2016 competition. What you're reading now is part of the first of five stages of the competition. Each stage fits with a separate piece of the overall project. The first stage is going to be all about laying out the rough blueprint for what is going to be implemented in the rest of the stages. During this time I'm also working on laying some ground work for some of the software that will be written in the later stages, mostly writing libraries and tools that I think I will need.

The second stage will be dedicated to fully specifying the protocol that will be implemented as well as creating a relatively heavyweight reference implementation of the basic protocol intended for use on relatively powerful hardware such as a desktop computer or a Raspberry Pi. The rest of the stages will be about implementing the protocol for embedded hardware, probably Arduino, and building various bits of hardware to show a complete working system.

Got Any More Info?

Soon. In my next post I plan to lay out a very rough plan for how I envision everything fitting together and solicit feedback as far and wide as I can. Stay tuned.