A project log for Virga - Cloud-Free IoT

A a fully decentralized, cloud-free, open-source IoT system.

AzdleAzdle 04/17/2016 at 03:310 Comments

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.