Project Byzantium situation report.
It's been a couple of weeks - far too long, really - since I've written anything about Project Byzantium. We've been hard at work when we haven't been working our day jobs though we haven't really made a lot of it public (or at least visible). A few weeks back an official developers' page was set up on the HacDC wiki and the mailing list was fixed at long last so you don't have to subscribe to a Yahoogroup and worry about cross-posting. Right now only a little conversation takes place aside from notifications whenver code is checked into our repository at Github. Unfortunately I had to miss the development sprint at the end of July of 2011 due to a process hitting a priority interrupt strongly last weekend (viz, my brother-in-law Grant getting married and Lyssa and I participating in the wedding ceremony; pictures forthcoming). However, I am told by the other Byzantium devs that a few packages were constructed for the OS but have not yet been checked into the Subversion repository for Byzantium. I added a few more this afternoon while hacking with a good friend yesterday afternoon.
On the mailing list we seem to have settled on some of the web applications we're going to package which a Byzantium node may wish to make available to users or not on a piecewise basis. Firstly, however, we need to pick a web server for them. After a short debate it came down to nginx or lighttpd. Apache is a little too resource-intensive for a live distro that aims to be light in terms of resource consumption as well as download size. nginx is fast and powerful and it can do what we need it to, but I'd still like to research lighttpd more before a decision is made.
We seem to have settled on using the Babel mesh routing protocol, likely due to its simplicity but, I must confess, not having to wrangle kernel modules does simplify things somewhat. All things considered Babel has all the features we want to implement while still being easy to configure, which means that the interaction of the control panel application and the implementation of the protocol is simpler. I committed an early version of this code on Saturday, and this seems to have been the case. Bzantium nodes will be able to configure one another if need be using AHCP but they can also pseudo-randomly set IP addresses on each of their wireless interfaces from the control panel if the user so chooses. Unfortunately ACHP requires a client that is not yet included by default in Windows, MacOSX, or Linux so other measures had to be taken. For nodes that will be using persistent storage to maintain settings between reboots, SQLite databases will be used to store node configs. As it happens SQLite is perfect for storing things like configuration options because it's lightweight and fast but is still a relational database even though it doesn't use a dedicated server to manage connections and queries.
On the up-close-and-personal front, work on the control panel application proceeds apace. I've based it on CherryPy, a high performance web application server written completely in Python. If you've not heard of it before, CherryPy does basically the same thing as Apache, IIS, or any other web server save for the fact that you can build whole applications around it in the same manner that you would use any other development library, or you can use it like any other web server if you write a little code that maps URLs to files; you can't just use it out of the box, I'm afraid. Some rather noteworthy web sites use it, which is one of the reasons that I decided to use it (plus, it's written in Python). It's also fairly easy to get up and running in a short period of time as the example on the afore-linked frontpage will attest to.
I know full well that I could probably write the Byzantium control panel in something more commonly used by the F/OSS community like GTK or QT, but my previous tries at graphical programming have been - how should I put it? - all failures. Even my attempts at adding an interactive interface to the OCZ NIA EEG haven't panned out, and don't get me started on the disasterous OpenGL programming course I took in undergrad. The one thing I am good at, however, is writing code that makes things happen under the hood, and these days if you have a desktop of any kind (and Porteus Linux does) there is a web browser of some kind already available. I may not be a web designer but I can put together enough HTML in an editor to let people make use of the back-end code, and then hopefully someone else can fix the HTML up and write some CSS to make it look good, or at least better than anything I could accomplish on my own.
Another fairly easy problem to solve was how to expose the output of logic from code written in Python to the user through a web browser. This is what web template languages are for, and they make things a lot easier. While I'm not a web monkey by any stretch of the imagination I do have a little experience with them from making what passes as a theme of this website. After a little research I found that a templating library called Mako would do exactly what I wanted (which is making the contents of variables available to the user without requiring blood sacrifices), be easy to program with, and give me the option of embedding Python code in the HTML if I needed to (though I'll do rather a lot to avoid that). If you check out the code from Github and play around with it (we haven't written an installer yet so you'll have to use the instructions in the wiki) you can try it for yourself.
Most of all we need security geeks to help us find and fix bugs! When you stare at code for hours every day it's easy to miss the obvious, and we want each copy of Byzantium to hit the Net as locked down and exploit-free as we can make them. If there are folks out there who could write and document a shell script or two for hardening Porteus, that would take a load off of me and I'll buy you the drink of your choice if we ever happen to be in the same place at the same time. We need more people who are willing to help write documentation. When we release v1.0 we plan to publish an e-book along with it that explains what Byzantium does and how it works, how to set up nodes, how to clone the media, and operational security measures that you should take when using a Byzantium mesh. For that matter we need translators, too! Specifically, we're looking for people who can not only translate text in the control panel into dialects of Arabic and Chinese, Farsi, Russian, and Greek, but who can help translate the e-book into those languages when it's ready. If you have experience with i18n in Python or HTML, please join the mailing list and speak up, we'd love to work with you. Free and open source projects are nothing without users, and we need users to help us improve!
In the best of all possible worlds I'd like to get a beta together before ContactCon in October of 2011. I'm going to this particular unconference to talk about Project Byzantium and get people (hopefully activists and fellow citizens of the Internet) interested in it, and a live demonstration of a small mesh would be the perfect way of going about it. If I can hand out credit card-sized mini-DVDs (mini-CDs aren't big enough for regular Porteus), so much the better. I'm also going so I can meet and hack with people from other projects so that we can work together; we (meaning, the Byzantium developers) would like the Project to be interoperable with other mesh projects out there (and they are out there, let me tell you...) and the easiest way of going about it is to work together. We're not trying to corner the fields of mesh networking or Linux distributions, we're trying to help people. If, for whatever reason Byzantium isn't perfect for what you're doing or the situation you're in but something else is, we'd like to try to help by making it possible for our respective projects to work alongside one another.