Add New Page: You are not allowed to add pages Select section/namespace. New page title.

2013 Development Roadmap


  • Security review: testing and analysis of code and implementation
  • Documentation for developers/implementers (e.g., Commotion APIs, system architecture, installation, etc.)
  • Continuous re-evaluation of Commotion safety warning against current feature set. (See:
  • Development of a native MediaGrid package for Commotion (
  • Gathering network performance analytics (historical & current)
  • User interface improvements for a better overall user experience
  • Backup tech support for Red Hook community network technologists
  • Develop and refine training materials and techniques

January - March

  • Automatic advertisement and discovery of mesh-local applications or services (e.g., chat servers, wikis, etc.). Released; official DR1 target feature
  • Local service discovery for Android devices: Released.
  • Service rebroadcast across mesh: Released; official DR1 target feature
  • Create an OpenBTS live image and default settings to allow GSM cell phone calls across the Commotion mesh: Released; Define separate feature targets;
  • Add data service (GPRS) to OpenBTS: mostly implemented in OpenBTS fork
  • Add tower-to-tower call handoff (Handover) to OpenBTS: implemented in OpenBTS fork
  • Create clear Commotion versioning definitions around features required for that revision
  • : Released testing branch (March 13, 2013), stable branch (May 21, 2013)
  • Implement delay tolerant networking to allow applications to transition between online and offline states
  • Decide on protocol: Selected Serval's Rhizome as de-facto starting point. Could still implement others (e.g., DTN2 or IBR-DTN) later.
  • Create an easy to use interface for Commotion node configuration. Released; official DR1 target feature
  • Create a portal for mesh-local applications. Released; official DR1 target feature
  • Change behavior of wifi user agreement page to capture traffic only on standard web port (80).
  • Decide on interim strategy for Commotion-Android given declining support for wifi ad-hoc mode in the Android operating system.

April - June

  • Develop harmful Commotion configurations for security testing on internal testbeds (moved from Q1)
  • * Include as extension of test documentation
  • Simplify Commotion documentation and develop a glossary of terms (moved from Q1)
  • * Unordered List Itemunderway, add links to glossary and use case documentation
  • Collect network performance data from live internal networks (moved from Q1)
  • * Fix collectd or switch to different data collection platform Switching to Zabbix ( as a monitoring solution
  • * capture historical data about node & network with visualizer
  • * Develop repeatable performance tests and scenarios based on real world data
  • Add typical modern security measures to all Commotion wifi (mesh and access point) using AuthSAE. Switched to IBSS-RSN. Implemented in DR1.
  • Investigate software localization protocols (i18n) for Commotion: Implemented in DR2
  • Develop site-specific custom profiles to simplify extension of internal networks
  • Document best practices for error reporting
  • Update Commotion websites
  • * Audit & update existing content
  • * Improve content management tools for better long-term maintenance of documentation
  • * Update and standardize site themes (Redmine and Drupal)
  • Improve key management tools to simplify the process of creating, joining, and identifying cryptographically secure networks and applications
  • Document the process for creating, adding, signing, and verifying Serval keys) * * Allow greater control over network resources by implementing basic Quality of Service features * Add a bandwidth control dashboard (building on DD-WRT/Open Tomato QOS tools)
  • * Update list of hardware known to work with Commotion downloads
  • * Fix existing bugs in Mac and Linux clients and create deadlines to reach Commotion feature targets
  • * Create and document methods for application developers to access/interact with Commotion security tools
  • * Develop a method to randomize node mac & IP addresses, making it slightly more difficult to link an IP address to a specific device
  • * Develop a preconfigured kit for Commotion demonstrations
  • Port Commotion to Raspberry pi for cost/portability * Select appropriate hardware (probably ARM-based) for a small, lightweight application server
  • Develop a script/documentation for use * * Preliminary exploration of a Tor package for Commotion (See: * Collect results notes
  • Append lingering questions h2. July - September * Implement all features necessary to bring the Android client to DR1 (Moved from Q2) * Set up more small scale, temporary networks to test, demonstrate, and refine Commotion concepts * Create better mesh visualizer or improve the existing network visualization tool (olsr-viz) * Make Commotion bugtracking & wiki more usable * Make Commotion work on a wider variety of devices * Develop a network administration dashboard Design and implement a tool for asynchronous “whole mesh” node configuration (BigBoard)

Design and implement a network data analysis tool * Add interactive voice/text automated response (IVR/ITR) packages * Design and implement a unified Commotion API, allowing developers to program for all Commotion platforms using a single set of commands * Use real world usage and performance data to design configuration profiles for specific needs (e.g., voice performance) * Improve hardware compatibility Port Commotion to Mesh Potato Check Commotion compatibility against OpenWRT hardware table ( * Refine Commotion's security threat models * Begin translation and localization efforts for common languages h2. October - December * Look for ways to apply health care harm reduction theory to the Commotion project. Contingent on threat model. (See: blog post) (Moved from Q2) * Reconfigure Commotion's route mapping tools (OLSR Fisheye) to reveal less information about a node's neighbor. Contingent on threat model. (Moved from Q2) * Create a Tidepools package for local mapping ( * Improve GSM cell phone support Optimize OpenBTS for embedded devices instead of x86 (DSP Optimization) Improve transceiver efficiency Improve data performance through GPRS adaptation * Continue translation developer docs training docs * Add an automatic crash reporter (from watchdog) to help network admins find and fix outages * Improve security of GSM cell phone calls across Commotion networks * Add a secure instant messaging application that does not rely on a central server or internet connection * Add software for secure voice & text communication that does not rely on an internet connection * Create a Commotion package for Windows, with an easy to use graphical interface * Official version 1.0 release Snapshot tech docs for 1.0 release official 1.0 security framework tools * Create a wiki that can be used offline and synced opportunistically (into 2014)

h2. Wishlist/Unscheduled

* Improve Commotion-OpenWRT build scripts to simplify network maintenance * Port Commotion to iPhone (Contract drafted; awaiting approval) * Add wifi handover, so access point clients can move from router to router without losing signal * Build support for more mesh routing protocols ** Add Babel support ( * Implement the 802.11s ad-hoc mesh wifi standard ( * userspace routing * userspace proxy * Network coding (performance/security) * Content distribution for robust redundancy (Erasure codes) * Plug & Mesh USB image w/attached antenna * Automatically adjust node wifi power to reduce radio interference and power consumption * Node-to-node secondary node configuration for decentralized network config (LittleBoard) * Design security threat models for specific populations/locations * Integrate Tidepools local mapping application with network administrator tools (BigBoard) to simplify maintenance of long-term community networks * Develop a Commotion administrator training kit incorporating software-based virtual machines to simulate a full scale network * Mesh authentic & anonymous stories (HRA) * Add support for sensor hardware (e.g., temperature, airspeed, etc.) for networked environmental data collection * Determine criteria and programmatic rules for “unusual” network behavior. Write scripts to notify network admins of anomalies and possible fixes. * Add DLEP support, which will create a standardized way to gather link-layer routing information without necessarily supporting those devices and protocols * Separate routes on a device across multiple “identities” in order to obsfucate mesh scale, and organization.