Sharpening Serval's Mission

We have been doing a bit of reflecting lately about what it is that we are trying to accomplish with the Serval Project, not because we wonder what we are trying to do or why we are trying to do it.  Rather, we have been thinking about what order to do things in, so that we can get something usable into people's hands as soon as possible.


To answer this question we went back to our motto of "communications anywhere, anytime", and did some thinking there.  We came to realise that we can probably refine that, and that by doing so, we will probably come to understand what are the important things that need to happen first, and what are the (in many cases equally important) things that we will work on once we have the initial objectives under control.


So here is our current thinking, and we invite any and all to give us feedback on this, and potentially change the line up.  What follows is our working position in the absence of any feedback.


We think that Serval's mission can be expressed more clearly as:

mobile communications for those in need

This more or less says what we have been saying all along, but it moves the focus from the technology to the people using the technology.  At the end of the day, we are only making the technology in the hope that it can help people.


So we then turned to think about what the "minimum viable product" is for Serval, and we settled on a short-list of the four things that really matter right now.  These are the things that we are focussing our resources on, and not until those are under control will we move on to our longer list of things that we have on the drawing board (some of which I will describe later).


The four things that matter now are:

• ease of use - the Serval software must be easy and intuitive to use, otherwise no one will use it, irrespective of how great and innovative the technology might be. 
• resilient phone calls, messaging and file distribution - these are the core functions of the Serval software, i.e., what it let's you do.
• strong, simple, security - security in mobile communications is so often an after thought, or severely compromised.  For example, the security of 2G and 3G mobile telephone systems has been thoroughly broken for years.  And when security is introduced into systems it has a bad habit of making life harder rather than easier.  Consider the complexity and interoperability issues suffered by IPSec as an example, indeed so complex that it's security benefits go largely un-used.
• no infrastructure needed - this is what is needed to make sure that we can most effectively help those in need, as it is the failure or absence of infrastructure (or affordable access to infrastructure) that is a recurring characteristic of those we are trying to help.  Besides, there are already plenty of infrastructure-bound communications systems.

We are tracking well on these points, and expect to have positive news on the progress of several of these points over the next month or so.


Once we have these under control, we have a long list of features that we will immediately turn to, use-cases and improvements, some of which we are working on now in a limited capacity, and that we are planning support for from the outset. In no particular order, this list includes:

• broad device support - For now we are happy to support a limited range of handsets, but we know that eventually we need to support as wide a range as possible, including non-Android phones.
• Traffic prioritisation/QoS - Right now our focus is on making the core functionality as solid as possible.  We have plans in place for some innovative QoS functions that we will implement as resources allow.
• optimising battery life - The mesh can already run for a full business day on a cheap Android phone, but we want more. We want to get to at least 48 hours of continuous operation on a single charge, and ideally much more.
• massive scalability - Our protocols are designed with massive scalability in mind, but there are aspects of this that we simply don't have the time or resources to implement right now.  We figure that it is more important to get it working at the "village scale", and once that is right and larger networks start to emerge, it will be quite natural for us to complete our plans for scalability.
• privacy and plausible deniability - For some people they take their privacy seriously, sometimes because their lives depend on it, or because the lives of the people they are in contact with depend on it.  Eventually our software should make sure that it can be configured to not betray any such information.  This is a considerable technical challenge, and one that it is not even certain that it is possible to achieve.
• journalistic applications - This is intrinsically linked to the previous point, as one of the main issues for journalists is keeping their sources confidential.
• complex “crisis mode” of operation - By this we mean some complex modes of operation where a network of phones automatically detects that a crisis is underway using various network heuristics (such as loss of cellular service, correlated vibrations or loud noise over a wide area, and to take some hithero undefined appropriate action.
• group coordination - We have plans to introduce a variety of work-group/team features, that will allow ease of communications and coordination amongst small teams of people.  These are based on the core features that we are working on now, and so will be natural for us to complete once the dependent features are complete.
• global mapping system and services - We already have an effective prototype of our mapping application that we demonstrated recently, and that we will continue work on as we are able.  This is a feature that has us quite excited, because it allows for a wide variety of coordinated and crowd-sourced activities through allowing users to create and share points of interest on the map, and to even automatically share the map tiles over the mesh, creating something like Google Maps that works without the internet.
• environmental monitoring applications - We already have some projects in mind here that will make use of the mapping system to make it easy to collect, share and visualise environmental data in the field, and so hopefully help people assess and protect the natural and built environment.
• -medical applications - We are quite excited about the possibility of making a cheap medical device platform that uses a sub-$100 Android phone as it's basis, combined with an open hardware port that allows the connection of an increasing number of off-the-shelf and custom medical attachments, such as pulse-oximetry, prick-less anemia testing, blood pressure, foetal heart-rate monitor and even imaging ultra-sound.  Support for additional functions and probes would be added to the platform overtime (with software updates over the mesh where required), as the interface would be open and flexible, doing to the medical device field what the smart-phone did to the software field. Extreme low-cost, field-upgradability, combined with resilient mesh communications to allow remote monitoring and collection of data and communication of alerts in infrastructure-deprived medical settings, we expect this concept to be highly disruptive to much of the medical devices space.

So that's what we are thinking about right now.  But we invite your input to help us shape this as best we can, and also to help us achieve these goals if you want to be part of the action or to help us resource this work.