NYCHackfestReport

Hackfest Report

The FreedomBox Hackfest at Columbia University was a huge success. We hosted 25 people of diverse talents and interests. Some folks came to learn, acquire DreamPlugs and do a guided install of Bdale Garbee's FreedomMaker. Others took up parts of the (task list)[http://freedomboxfoundations.org]. We learned a lot about the boxes, ideas for routing, data modeling, and security concerns. Lots of people pitched in on the tasks list, and descriptions of that work are below. Most importantly, we had a lot of fun meeting each other and collaborating. If you are interested in any of it, please ask about it on the discussion list, especially if you want to help!

Huge thanks to everybody that participated. Many people came by just to learn about the FreedomBox, talk about their use cases and offer encouragement. That activity is very helpful, and we appreciated the fresh perspective.

We intend to do more hackfests, perhaps in more cities in the near future. This weekend was a great success in progress, bug squashing, design, and first-draft implementation of key FreedomBox infrastructure.

Thanks again to everybody and especially to Columbia University, Elizabeth Boylan, and ISOC-NY for logistical and material support.

Progress and Activities

Port Santiago

There is a problem we have been referring to as the "magic routing problem". It is the question of how two FreedomBoxes find each other on the internet and establish communication, even if one or both boxes are firewalled and neither is findable via DNS. We called it "magic routing" because we hadn't started to design the routing system and so we had to assume it happened by magic.

Our solution to this problem is to piggyback on the Tor network. Hidden services rely on Tor for routing and discoverability. The system works quite well and the Tor project does excellent work at maintaining that system and strengthening it against attack.

Nick Daly and Ian Sullivan built a simple server that listens on a local port and is reachable from the outside world by a Tor hidden service. It accepts authenticated queries and responds with information. For example, it can give your IP address to friends you trust.

To avoid burdening the Tor network and also to avoid the delays associated with using Tor, Port Santiago will allow two FreedomBoxes to decide on a faster (though less anonymous) method of communication. Subsequent communication will happen on that channel.

Right now, we are using Santiago to discover a FreedomBox's IP address for the creation of encrypted proxy tunnels. This will allow a FreedomBox to provide uncensored, unmonitored internet access to a friend who is stuck behind a national or corporate firewall.

Nick did the heavy lifting on this work with help from Ian Sullivan and in consultation with many of the Hackfest participants. Nick's documentation and code will be up on github soon.

Neruda

Port Santiago lets FreedomBoxes provide some basic information via a Tor hidden service, but users need a way to find out the onion addresses of their friend's services. The most obvious way to do this is with distributed hash tables (we also considered less obvious methods that piggyback on existing infrastructure, like bit.ly links). Issac and I planned out the DHT, how to access it, the data structures, and API. We are calling this system Neruda.

Neruda will allow users to take a GPG key and look up a user's Santiago onion address. Issac Wilder is speccing this out and coding it.

One benefit of reaching Santiago via a Tor onion address is that FreedomBoxes do not need to update Neruda very often. Even if your IP address changes, your onion address shouldn't. Updating your Neruda record is a rare event and it is acceptable to refresh Neruda's tables relatively infrequently. This might allow us to devote fewer resources to it.

Key Signing

FreedomBoxes are going to make a lot of use of GPG to authenticate identity and sometimes to encrypt data as well. To strengthen the web of trust, we did some key signing and also introduced some participants to gpg, generated keys and taught key management.

This page is also available in the following languages, thanks to the work of our excellent translation team: