Over the past few years, The Work Department has been active in building community wireless networks in Detroit. We have experimented with different types of hardware and software, and we have helped neighborhoods build useful networks to share internet connectivity and provide local file sharing. Something we haven’t had much of an opportunity to explore, though, is building more elaborate systems that leverage the unique traits of mesh networks.

As we worked through other parts of the Commotion project, we brainstormed ideas for wireless mesh applications. We noticed that our ideas would often replicate existing web services — e.g. a local fileserver for music or movies, or a local message board for neighborhood discussion. We began to wonder what would make a community wireless application more appealing than using a centralized Internet-based application. We agreed that it wouldn’t be enough to offer someone the simple satisfaction of knowing their data is decentralized… there would need to be some other benefits to using a local application.

What would these benefits be? What is special about the architecture of a community wireless mesh network? In pondering these questions, we considered what is provided by these networks — earlier, I mentioned that the networks provide internet connection sharing and local file sharing, but that’s only a part of the story. These networks also provide something much grander: they become community institutions. Unlike the Comcast hardware that is bolted out of arm’s reach on a utility pole, our community wireless equipment lives on our porches, in chicken coops, in our bell towers, and next to our desks. Each piece of equipment has a story behind it. We know who held the ladder while it was being installed and who lent their hammer drill to run a cable up to it.

A community mesh wireless router’s IP address is more than a 32-bit number. It has history and meaning. How can we build applications that reflect and enhance this?

I had the good fortune to meet Adam Magaluk at Detroit’s hackerspace, OmniCorpDetroit. Adam works on mesh wireless systems at Illuminating Concepts, and is deeply interested in OLSR and embedded systems. We are both young programmers and share a preference for modular and decentralized systems. During our initial conversations and research, we ended up favoring web browser based application development. This way, people who might want to use an application wouldn’t have to download anything. Since today’s web browsers have lightweight streaming messaging capabilities with WebSocket, we would have a lot of flexibility in application development.

To build a web browser based application, we can start by limiting the amount of work the server does to a bare minimum. In the circumstance of a chat application, we can say that the server should simply keep a record of who is connected to a chat session (in a sort of subscription model) and then, as messages are posted, transfer messages from the publisher to the subscribers.

Limiting the duties of each mesh node to passing messages and keeping track of connected clients ends up being beneficial in two ways: it conserves computing resources and encourages decentralized application development. Since most community wireless routers are low power, low cost devices running with MIPS CPUs and 4-16MB memory, the former benefit is clearly attractive. The latter benefit is a bit more complex — do we really need a fully decentralized application? Why can’t we just have a little bit of local node storage? It sure would make things simpler if we could have a local data cache instead of trying to develop a peer-to-peer storage system, but for now we’ll embrace this limitation when designing applications.

To begin experimenting with the core concepts of lightweight messaging systems that can work with community wireless network hardware, we built an example application to provide WebSocket service to clients connected to a Commotion access point. This service can be utilized by anything on the network, but in our first example application, it is employed by a web application served from a publicly accessible LuCI URI linked from the splash page. The application provides a simple interface to chat with other people who have connected to the local node’s websocket chat system.

Thanks to the work of Hans-Christoph Steiner (from The Guardian Project) on the jsoninfo plugin, OLSRd can easily provide some useful network information as a json object to web applications. Above the network layer, our WebSocket message server can provide data about connected clients and possibly other information in the future.

After you get your head wrapped around the WebSocket server, its underlying restrictions, and the mesh network playing field, you can start to imagine various situations where local messaging might be interesting. With an idea in mind, a developer can easily jump into a familiar web application development environment. If you have used things like WebSockets or socket.io, you already understand the core concepts of writing a mesh network application using these building blocks. As we build more features into the platform, it will offer more options for developers.

Next Steps

Currently, the system provides a messaging service that doesn’t utilize node-to-node mesh connections. As it stands, we can develop some interesting and useful applications, but there is definitely a lot to gain from adding functionality and possibly revamping things in the interest of security or privacy.

Our next major task is to begin experimenting with systems that- allow neighboring nodes to subscribe to each others’ connections. To use the chat application as an example of how this might be used: a chat participant might be able to start a conversation with people connected to their own mesh node and its next neighbors, or some other arbitrary number of hops.

We would also like to experiment with simple implementations of shared / distributed storage. Again, to use the chat system as an illustration, we could have chat participants store chat logs and offer them to new participants who broadcast a request for the last N minutes of conversation. There is a lot of distributed storage work for us to reference, of course, so we have our work cut out for us!

Aside from enhancements and features in the messaging system itself, we have plenty of ideas for the actual applications. We have recently been prototyping games that could use a neighborhood or multi-neighborhood mesh network as a playing field. We have found that prototyping and brainstorming games is an enlightening process: it helps explain the ins and outs of the technology to people, and also presents clear challenges to create obvious and attainable goals within the technology’s limitations. We’ll be sharing some “capture the flag” style game ideas that utilize a “meshaging” system during the next couple of weeks.