RILink software stack

In case walls of text aren’t your thing, check out these pictures. Hopefully you’ll find them pretty, but more importantly, we really hope that this will help clear up misunderstandings and confusion preemptively, and give everyone a better understanding of just what the Roaming Initiative project is trying to accomplish.

How most internet users have their homes set up now

Typical existing internet setup

Currently, the typical setup is a router acting as intermediary between the ISP connection and multiple home devices. The ISP connection is usually managed by a device such as a cable modem or satellite dish, which connects to your ISP’s higher infrastructure. If you want access to Hyperboria, you have to do it through your ISP-based clearnet access.

How RI internet access works

How RI internet access works

Roaming Initiative takes the existing ISP model and turns it on its head. Instead of getting Hyperboria access through the clearnet, you get clearnet access through Hyperboria.

This works by building a physical Hyperboria mesh in the local area, free for anyone to access using commodity hardware and libre software. Your RILink mesh node takes the role of the cable modem, providing access to the local CJDNS mesh. That gives you access to CVI gateways available on Hyperboria, which act like ISPs - you pay for the service, and you get clearnet access through that service’s gateways.

There are some really nice consumer advantages to this - free access to Hyperboria, which lets you shop around ISP websites before buying anything, and trivializing service replacement. ISPs get the most mileage for abuse out of two things being difficult/expensive: finding alternative service providers (impossible in areas with a local monopoly), and switching from one service to another. The shared infrastructure means you can buy your internet access from any provider in any country in the world, and switching to a different provider is 15 minutes of online forms and configuration. ISPs can’t afford to be evil.

How local physical meshes will be set up

Local mesh geography

The network backbone will be made of RITower devices (see the hardware page for more details) that are enabled with both WiFi and WiMax transcievers for mesh networking. WiMax is a WiFi-like protocol that can achieve good throughput at long ranges, but runs at frequencies controlled by the FCC (so licensing fees are an issue if you want to buy RITowers of your own for use in America). As you can see, the two towers shown are able to communicate with each other (green line) without being in WiFi range (red circles). RITowers contain UPS (uninterrupted power supply) components so that they can stay online for a certain amount of time without power.

While these provide a fast scaffolding for the area meshnet, they’re not the only devices contributing to mesh availability. Any WiFi or WiMax device that speaks CJDNS expands the reach and signal strength of the network, and provides redundancy in the event of the FCC suddenly revoking licenses for political reasons. In a sufficiently populated network, all the RITowers can go down without leaving any users without internet. These auxilliary devices can be owned by anyone and made out of anything, although we’ll be selling RILink devices specifically for this purpose, containing software designed for easy CVI client configuration.

A CVI gateway can be part of the local network (for example, the software can be installed on an RITower with a clearnet backhaul quite easily), or it can be run in a remote location, such as a server farm/datacenter. The latter is how we’re going to handle gateways for the immediate future, to ease the infrastructure hassle of frequent software updates to RITowers as the software matures (it’s a lot simpler to update a few Linode VMs than a vast fleet of outdoor hardware). In remote areas not well-serviced by ISPs, it can even make sense to start a “ghetto CVI service” using an old desktop and the gateway software in a location where you can get a decent ISP connection (although you really should clear it with your ISP before you start reselling bandwidth, legal restrictions may apply, and your ISP’s technicians are more useful as allies than foes).

RILink usage and software stack

RILink software stack

This graph shows the core software available for every RILink mesh node. This doesn’t include any of the fancy extra things that the upper-class hardware models get, like Amanda Backup and a local MediaGoblin server - just the stuff you can expect to have on anything from a Valkyrie to an Asgard.

First of all, the RILink is designed to sit in front of a home router, though the Valkyrie is the best suited to take over both roles thanks to its 4 ports in the back (versus the one port of other RILink classes). If you don’t plan on using home wifi, you can get a good ol’ 10-port ethernet switch instead, but generally speaking you’ll want home wifi.

As for internal software, everything is color coded in the diagram. Orange = CJDNS/Hyperboria. Blue = system utilities. Green = configuration, and red = the base OS. The mesh and CVI client functionality is all controllable through the Plinth web administration interface (or rather, a fork that isn’t branded up with the FreedomBox logo). The open-source Plinth plugins we’ll be developing will allow easy, simple, high-level manipulation of CVI client properties, making it easy switch between CVI services.

Not pictured is pingsort, a piece of software that maintains a sorted list of IP addresses based on their ping latency. This background service allows you to switch to a faster gateway server when one is available, and is really useful if you travel a lot.

What is hopefully apparent from the diagram is the way that the clearnet is accessed through a gateway server within the Hyperboria network.

CVI gateway software stack

CVI Gateway stack diagram

The gateway stack is in many senses simpler than the RILink client stack. Of course, VPN administration has its own sets of complications, even with high-level web interfaces designed to abstract the scary away. The gateway stack will share as many technical elements with the RILink stack as possible to avoid duplication of effort and promote consistency and ease of use across all our products and open source projects. The VPN server software is OpenSwan, as its kernelspace IPsec usage gives it the speed advantage that’s critical for such a use case. It also gives an interoperability edge over OpenVPN, which is useful if you’re setting up a laptop, phone, or tablet to act like a mobile CVI client.

Here at RI, the primary developers and users of the CVI gateway system, we use Debian Stable VMs in datacenters as our primary gateways, with a slow introduction of the software to RITower devices. Datacenter gateways are most efficient for international users, RITower installations are most efficient for local use (the pingsort utility that comes with the RILink stack will choose the best available gateway for clients automatically). Starting with the datacenter gateways allows for easier software integration and testing, is good for scaling, and provides a nice environment for developing features that RITowers will need (like data synchronization) without an immediate time crunch over our heads.

Meta notes about this post

This was made possible by Google Docs, Inkscape, and git.

Google Docs let me create and edit these graphs easily on a computer with a big screen, and then download and transfer them with my tiny-screened development machine.

Inkscape does a beautiful job of hand-editing SVG files, but did you know it can also be used for command-line exporting to PNG? That, combined with my newfound discovery of the “basename” command, made it trivially easy to batch convert the original svg files to have png export copies available in a single line of loopy bash.

for i in *.svg; do inkscape -z $i -e=$(basename $i .svg).png; done;

Git was probably the biggest deal for this post, oddly enough, and the motivation for including these credits at all. While the blog is not in a public github repository yet (maybe someday, I’m still deciding if it makes sense to do that at all), I did finally set up git so that I could work on it from my laptop in a local environment, rather than edit the live copy (in retrospect, the way I was doing it before is kind of insane). Without being able to edit and test locally for hours before deployment, this kind of post would have been impossible. And I feel like I’ve also bettered myself by learning how to push and pull on a repository via SSH on a machine I own, rather than some easy-peasy github server.