Sailing To Byzantium v0.2a.
Last weekend the Project Byzantium development team assembled once again at HacDC, this time to close out tickets because we're getting ready for the second alpha release of Byzantium Linux as well as the launch of the official website. I think we're making pretty good progress - about half of the tickets in the bug tracker are closed (i.e., have been fixed) and we're lining up the next set of features. Some weeks back a group of hackers associated with the Zero State took over a pub in the UK and put Byzantium Linux through its most difficult test yet, and in the process discovered a number of drawbacks and shortcomings that we've been busily fixing. I'm fairly confident in the efficiency of a Byzantium mesh network at this time because it stood up to the stress tests they put it through, namely, bootstrapping a new Bitcoin client (which involves downloading a 1.1 gigabyte database) and setting up a Tor node on the mesh. They also tested the mesh-to-Internet gatewaying functionality by running their backhaul link through a smartphone and we're told that it worked admirably.
The goal of last weekend's development sprint was to close out as many tickets as we could because we're getting ready for the next alpha release of Byzantium Linux. To that end, we gathered at HacDC on Friday night, ordered pizza, and sifted through the list of open bugs to find our targets for the weekend. Taking a page from the Zero State's playbook I commandeered one of the whiteboards and set up a kanban of tickets and hackers, and we claimed the bugs we were going to fix. While the kanban method of tracking was originally developed for assembly line management it also works very well for development sprints because it helps you keep track of where the sprint is. As each bug is fixed it was erased from the board, and a list that keeps getting shorter is a powerful psychological motivator to keep going.... to fix just one.. more... bug. I think we cleared about half of the kanban that weekend, including some of the most difficult to fix bugs we had open at that time.
One of the most difficult things to get working was the captive portal, the software that intercepts requests for websites from users and redirects them to the frontpage of a node. If you don't otherwise know anything about the network you're on, you can't assume that people will do the right thing because they don't know the right thing. So, a little network sleight of hand is employed to make the user's hand held think that every website they could browse is the mesh node they're associated with, they're shown a simple web page that gives them the nitty gritty (which we really need translated - any takers?), and then flips the user to a directory of services running on the mesh node. This wound up being far more difficult than we'd thought, but not because IP tables sucks particularly (it does suck, let's not mince words, but for once it wasn't the culprit). After messing around with it for a month or two I sat down with a good friend who was visiting for a few days and we isolated the bug in about an hour. The bug happened to be in the miniature web server-cum-gatekeeper daemon that I'd written using CherryPy, which we discovered doesn't like to be configured to listen on a subset of IP addresses of a particular system. It's an all or nothing kind of framework, and after removing some code It Just Worked.
We're also working on getting a real website up and running rather than pointing everyone to HacDC's wiki. We've got a really nice framework in place and it seems to be stable, we just have to finish adding content to it. Unfortunately some of the elements of the CMS we're using can't be edited online and will have to be hand-hacked on the back end, but that's more of an irritation than anything else. Hopefully we'll get the website launched before CarolinaCon. Which brings me along to an announcement that I've been putting off for a while: We've submitted talks to a couple of hacker cons and we've been accepted at CarolinaCon in May. Ben the Pyrate and I will be giving our Byzantium presentation, updated to take into account the advances made in the past year. We've also submitted a proposal for HOPE Number Nine but we don't know if it's been accepted yet. There is also talk of submitting a workshop proposal for HOPE but we're still discussing that.
In other news, Project Byzantium was approached by the Mount Pleasant community mesh network project, a project which is bringing free wireless networking to parts of the DC metroplex that aren't well connected. They are using software developed by the Commotion Wireless project, which shares many of our goals to set up a wireless mesh network. HacDC is discussing the purchase and installation of a node on the roof of Saint Stephen's to asist them in this project. This does not, however, mean that we're giving up on Byzantium Linux; quite the contrary in fact. The mesh nodes that the Mount Wireless project is setting up are quite expensive, on the order of a few thousand dollars each. That's nothing to sneeze at, and the cost represents a fairly high barrier to entry for a lot of people. The reason we're working on interoperability with the Commotion Wireless firmware is because our respective projects occupy complimentary niches in the wireless network ecosystem. Byzantium nodes can provide connectivity where it's financially infeasible to do so because our software is free and designed to work with commodity, general purpose hardware (such as a cheap netbook from the corner drugstore); conversely, the high end mesh nodes running Commotion provide ideal backhaul links. Also, Byzantium can run whatever servers or web applications you can think of, whereas the Commotion software is designed to act as part of the infrastructure.
I also noticed something in the past few days, and I think it means that our respective projects are beginning to take off. On 30 March 2012 the Washington Post published an article about the Mount Pleasant wireless project. For the article Rob Mancini, Chief Technology Officer of the Washington DC city government was interviewed and said that he'd be watching community mesh networks very closely because they are potential threats to national security and might attract terrorists. As a developer of an Internet anti-censorship project, I am obligated to state the following:
By making that statement, Mr. Mancini, you have just used the same justification that some of the governments on this list use for their Internet censorship programs, as well as for their reactions to political dissidents in their respective countries. It pains me to say this, but just as one cannot simultaneously celebrate peace and prepare for war, one cannot simultaneously be part of a country which extols freedom of connectivity and information in other countries (I speak of the US State Department's anti-censorship projects) while spreading fear, uncertainty, and doubt about those very same freedoms in one's own.
Things are beginning to speed up for Project Byzantium. When v0.2a is released we'll post far and wide about it. As before, we need people who would like to help us write documentation, code, test releases (and release candidates), and translate text into different languages. If you'd like to help, please join our mailing list. If you have any comments or suggestions we'd love to hear from you.
Toward CarolinaCon! Toward HOPE! Toward v1.0 (eventually)!