Monday, December 3, 2012

Rhizome over MDP

The Serval Mesh uses our own overlay network, rather than relying solely on any underlying IP network.  This decision was made for several reasons.

First, we knew that IP over ad-hoc WiFi has a number of problems, many of which are a direct result of interoperability problems among and within ad-hoc WiFi implementations.  Such interoperability issues could manifest as, among other things, an inability to deliver unicast IP packets, but allowing broadcast IP packets to be delivered just fine.

Second, we have planned from the outset to diversify our radio options beyond WiFi and other traditional wireless-IP based solutions. In particular, we have had our eye on low-bandwidth communications in the ISM bands.  At low bandwidth IP encapsulation would incur unnecessary overheads. Also, allowing compatibility with IP would mean that any such mesh would soon be drowned out by the general IP chatter of hosts, because most modern software is no longer designed with dialup and sub-dialup speeds in mind.

Third, it allows us to use public keys as network identifiers, and so gain some very nice security characteristics for free.

So we created the Serval Overlay Mesh (SOM) and Mesh Datagram Protocol (MDP) as our solution to this. We have already implemented encrypted voice calls and Serval DNA resolution over MDP.

That left the Rhizome store-and-forward file and data distribution system as the sole part of the Serval Mesh dependent on IP networking and unicast packets.

So this week I finally got around to implementing Rhizome over MDP, using a protocol similar to TFTP, but with each request asking for up to 32 packets at a time to improve throughput.  We also have some ideas for buffering and handling packet loss and out-of-order delivery, which we hope to implement soon.

In the process we also revamped Rhizome transfers to stream directly into the database, instead of having to be written to temporary files first.  We also hash the files as we receive them, so that there is no big time hit at the end of reception.  This is important for slow devices, large file transfers and situations where servald's responsiveness is important, such as when carrying a voice call.

But for now, we are happy that we can transfer arbitrarily large files using only broadcast IP packets, which makes it much easier to create useful mesh networks using existing ad-hoc WiFi capable equipement.

The image below shows servald running on a Dragino, and me poking it to see if a file has been received.  The file "foo" is duly received after a short while.

Thursday, November 29, 2012

Syria in the Dark

Today it was announced that all Syria was cut off from the internet, and parts of the cellular telephone networks were shut down as well.

This is an example of a "politically induced disaster" as compared to the more familiar "naturally induced disasters", such as those resulting from bushfire or earthquake.

Whatever anyone may think of either the Syrian government or the rebel forces, what is clear is that an entire country suffers and is made more vulnerable by this kind of act.

It is thus suffering and vulnerability --- whatever the cause --- that the Serval Project seeks to alleviate.

And so when we hear news like this, the response in the lab is "code more", so that we can start delivering resilient communications solutions as soon as possible.

Wednesday, November 21, 2012

US Carriers Continue to Seek to Avoid Emergency Preparedness (and all Other) Regulation

In the aftermath of "Super Storm Sandy", questions are being asked in the USA about carriers, their preparedness for handling emergencies and disasters, and in a subtle way, whether the carriers are willing to incur the cost of such preparations, or whether they should be free to put profit ahead of the safety of the people, and avoid as much regulation as possible.

See, for example:

Meanwhile, the people on the ground remain vulnerable to the whims of carriers, when they most need communications.  This is one of the many reasons why we continue work on the Serval Project, so that we can re-empower people to solve their own communications needs.

Thursday, October 25, 2012

Open Writing of Serval Documentation

As the Serval Project is based in a University, we have a need to write academic papers.  However, such papers take a while to write, get peer reviewed and published. This is a problem since Serval is also an open-source project, and we need to get information out to the community in a timely manner.

So I am trying an experiment.  I am progressively moving all paper preparation activity into our github repository (

Some legacy documents will be in LibreOffice /OpenOffice format.

For new documents I will be aiming to use LyX (a LaTeX frontend), because commits that change documents will result in meaningful diffs between versions.  Also figures exist as separate files, and so are easier for people to access, update and/or reuse.

One of the nice advantages is that people can submit corrections, view older revisions, or submit "bugs" or "feature enhancements" for improvements to the document.  Overall, it seems like it should result in better papers.

Anyway, the first document there is a document describing Serval Rhizome.

Monday, October 15, 2012

Secure Communications Is Valuable

Well, we already knew this, but it is pleasing to see when others create things that are similar to what we are doing.  In this case, it is Phil Zimmermann (of PGP fame).  He has a startup called Secure Circle offering secure telephony and messaging:

The actual company website is here.

Similarities between Silent Circle and Serval include the use of ECC for the crypto (we are using Curve25519 (effectively 251 bits) while they are using the NIST 384-bit curve), and some of the telephony services being offered.   There is no reason why we couldn't move to 384-bit or stronger crypto, but we do not see the need at this time.  It would be quite possible for us (or someone else) to switch out the crypto system for a different one should people desire to do so. The most practical reason why we are are not yet on a longer ECC system is that the NaCl library that we use is yet to support one, which reflects, in part, the fact that a (well implemented) 251-bit ECC system offers ample security for the time being.

Differences include that Serval is free (as in beer and as in liberty) and open-source, and rather importantly, that Serval technologies are designed for resilience, and do not require a cellular network or internet access to facilitate communications.

Monday, October 8, 2012

Using Serval as a Basis for Environmental Monitoring

One of our developers, Corey Wallis, is in the midst of a project with some of the other researchers in the Flinders University Disaster Research Centre (DRC) where they are creating a system to acquire temperature and humidity data from mass gathering events, such as concerts and sports events.

This involves both fixed and mobile devices with sensors continuously collecting data for analysis both at the event and on-line.

One of the tricks is that we can't rely on cellular service being available at these events.  Also, we want all of the field teams who are gathering data to also be able to visualise and act on the data, so we need a many-to-many distribution scheme.

These features make it an good fit for Serval Rhizome, our store-and-forward/Delay Tolerant Networking (DTN) system, that is able to handle both of these requirements, and will result in a very versatile system that can be used anywhere in the world.

Corey has made some good progress on the hardware and software for the data gathering, as can be seen in this blog post:

Among the next steps are to actually integrate it with the Serval Mesh software so that the data can be shared among the field teams and analysis staff.

Saturday, October 6, 2012

The Serval Technology Stack

Back when we started with the Serval Project we were focussed on creating a proof-of-concept that showed the potential of the concept of enabling mobile telephones to communicate directly, and allow people to communicate in difficult situations.

As a result of that approach, we took largely existing VoIP and mesh routing technologies and fitting them into a mobile telephone.

We already had ideas at the time that there was a better approach. This was reinforced by our early experience where we found that the combination of SIP was very sensitive to packet loss during call setup.

To cut a long story short, we decided to implement our own suite of mobile mesh oriented protocols overlay network, and mesh oriented protocols and technologies to replicate the core functionality, not just of SIP/VoIP, but also UDP-style datagram services, file distribution, SMS-like services and more.

Today I presented at #IS4CWN describing this new technology stack and explained a lot of our reasoning behind it.  I have been meaning to document some of this for a while, and now it has finally happened.  Now that I have some diagrams and slides, my intention is to write a series of posts explaining the various parts of the new Serval technology stack.

For this post I want to start with an overview of the new technology stack, which I will then expand on each part in future posts.

Starting at the bottom, we have the various base layers that the Serval Mesh protocols all might be encapsulated in.  While the current implementation is an overlay encapsulated in IPv4 UDP packets, the overlay was designed to allow the kind of flexibility reflected here, with digital packet radio and other transports being anticipated from the outset.

The trained squirrels is somewhat tongue-in-cheek, but serves to represent that we are thinking broadly about the form of possible transports.  It is hard to write kernel drivers that can expose a fleet of trained squirrels as a first-class network interface on a variety of operating systems, and the same goes for packet radio and other interfaces.

This is a good reason for us to pursue an overlay network approach, because it avoids the need for kernel cooperation, even if using strange transports.  It also allows us to step back from some of the overheads and anachronisms of IP networking that are not appropriate for low-bandwidth or high-latency links, such as packet radio.

This naturally leads into explaining the nature of the Serval Overlay Mesh protocols itself.  As mentioned, one reason for pursuing the an overlay model is to allow the use of non-conventional packet transports.  Another reason is to avoid the pain of IP address allocations.  IPv4 doesn't have enough address space to allow random self-allocation of addresses at a global scale.  It also turns out that IPv6 doesn't either, because there are only 64 host address bits, and there are more than 2^(64/2) people and devices in the world, which is the practical limit for random address allocation.  Structured address allocation is not feasible for mobile mesh networks that are intended to provide resilient communications.  Further, not all mobile phone platforms support IPv6.

So our view is that IPv6 doesn't really offer any compelling advantage for our use-case.  Our approach was to instead use 256-bit Elliptic Curve Cryptography public keys as network addresses.  This also makes end-to-end encryption of communications between nodes trivial, because a Diffie-Hellman shared secret agreement process can be used to facilitate the use of a stream cipher.  And this is exactly what we have implemented for our Mesh Datagram Protocol (MDP), which is otherwise very much like UDP.

The transparent encryption offered by MDP is used to host our Voice over Mesh Protocol, which then benefits from this.  Of course security isn't just encryption, and there are authentication and man-in-the-middle attack issues to be considered.  But I will leave that discussion for a future post.

So that covers the right hand side of our protocol stack, which is all the real-time protocols.

The left hand side covers the Rhizome store-and-forward or Delay Tolerant Networking (DTN) protocol and applications layered on top of that.  Full explanation of that will also be the subject of a future post.

Friday, August 3, 2012

It's competition season

I have been named a finalist in the South Australian Science Excellence Awards this year, which is really nice.

You can check it out at:

In a rather surprising turn of events there are four people from the University department where I am based, not bad considering that our department is no where near 1/22 of the science output of the state.

This year they have announced a "people's choice" award that has a basket of fine South Australian chocolates as the lure to get people to "like" the science awards facebook page.

If you are not adverse to facebook, feel free to vote for me so that we can win the chocolate hamper and share it with our supporters.  You can vote every day until 17th August 2012 to maximise our chances of winning the hamper. The link to vote for me is:

Sunday, July 15, 2012

The Serval Project - Reflections Two Years In

It is now almost exactly two years since we made the first public demonstration of the Serval Project's vision for keeping mobile phones working without cellular networks or infrastructure, and it seems right to recap where we have come in the past year.

A year ago, the software was still more or less the same as was demonstrated in the video linked above in mid-2010.


Support for the project consisted of initial seed funding from the Awesome Foundation, and a generous research fellowship from Flinders University, that freed up the majority of my time to focus on the project.  The project then received a further significant boost with my being granted a Shuttleworth Foundation fellowship.
Dr. Paul Gardner-Stephen in South Africa, while meeting with the Shuttleworth Foundation.
This combination of University and foundation support has proved to be amazingly effective.  The University has provided facilities to accommodate the project, and access to a variety of expertise and relevant research interests, especially in the disaster research space, where Flinders University is particularly active and well respected internationally.  The Shuttleworth Foundation has provided the financial means to free up all of my time to focus on the project, as well as employ developers and other resources to allow the project to drive forward much more quickly than would otherwise have been possible, and to enable me to keep some focus on the big picture, instead of having to do all the technical work myself.  Both organisations have the public interest at heart, and have been particularly accommodating of the unusual nature of the project, and so the relationship has worked much better than I had even hoped.  This is something of which I am continually grateful.


Further resources were added due to support by the Open Technology Initiative's Commotion Project, which is focussed around resilient communications systems to protect against human rights violations and what might be generally called "politically induced disasters" as compared to natural disasters.

Using these resources, the Serval Project has set about transforming the proof-of-concept demonstration software of 2010 into a production quality system.  This has resulted in near complete replacement of every component.

Instead of using Asterisk and SIPdroid for voice calls we have implemented our own mesh-oriented voice protocol and programs, resulting in a much smaller, faster program.

The underlying mesh network that allows the phones to communicate directly with one another, and to relay calls and data for one another has been redesigned and reimplemented from the ground up, with high-grade security baked right in.

The Rhizome store-and-forward data service has been created, and then rewritten to take advantage of the new mesh implementation.  MeshMS (Mesh-based SMS) has in turn be reimplemented to make use of Rhizome, and has been demonstrated delivering a message between Africa and Australia, using nothing more than three mobile telephones.

The user interface has been completely redesigned and reimplemented, to give a much more integrated user experience.
Screen-shot from a nightly build of the next planned release of the Serval Mesh, featuring redesigned user interface.

Increasing Recognition

This year has also seen a continuing increase in recognition of what we are doing, both locally and internationally.  Either myself or the Serval Project has been short-listed or awarded in the Rolex Awards for Enterprise (short-listed), South Australian Tall Poppy Awards (short-listed, announcement of winners pending), South Australian Science Excellence Awards (short-listed, announcement of winners pending), Flinders University Early Career Researcher Awards (awarded), Anthill Smart 100 (awarded), NexExplo Top 100 (awarded), and Ashoka Change Maker's Competition (short-listed).
The Serval Project was one of 11 finalists in the Ashoka Change Makers Citizen Media competition.
The Serval Project was one of the top-100 innovations named in the Netexplo list of 2012.

The Serval Mesh software has now been downloaded more than 13,000 from the Android Market.  More than half of the downloads have been from France, we presume the result of our appearing in high-profile news service La Monde, and the involvement of exchange students from INSA Lyon in the Serval Project.

Increasing Collaboration & Impact

But perhaps most exciting has been the increase in collaboration and impact as we begin to reach sufficient technology maturity for our software to be used in trials, and hopefully in the next 12 months in operational deployments.  

Collaborations with researchers in South Africa and Israel have already resulted in one journal paper being published, and another two are in preparation.  Perhaps most importantly, these collaborations are a clear marker of the Serval Project becoming international in its endeavour and undertaking, so that in the long term it will not fall upon our shoulders alone to develop and maintain the technology.

But most exciting of all has been the two trial deployments, one in Nigeria as part of a human rights/citizen journalism project, and the other in New Zealand with the New Zealand Red Cross IT&T Emergency Response Unit by trialling our technology at their week-long KiwiEx'12 training exercise.
Members of a community in Nigeria familiarise themselves with the Serval Mesh software.

The relationship we have developed with the New Zealand Red Cross ERU has been tremendously helpful in a number of ways.  It has given us the opportunity to understand, first hand, what the needs of an operational deployment in a disaster zone are, and this has directly shaped the development of the technology, and continues to do so.  It has also opened the doors to other NGOs and even UN agencies to discuss our technology and how it might be able to be used by those organisations.  
Emergency Operations Centre at KiwiEx'12, where Serval Mesh technology was trialled.

A recent outcome of this is that along with the NZ Red Cross and other partners who trialled technology at KiwiEx'12, we have been invited by the UN WHO to put together a proposal for a standardised resilient field data collection capability for their consideration.


So overall it has been a year of getting ready and making tentative first steps of engagement with the international community.  Together with the software development progress that has been made the feeling is that this year has been one of preparation for broader engagement and increased impact in the year to come.  By continuing to focus on the humanitarian/disaster response use-case for the Serval Mesh technology, and the relationships that we have already begun to create in that space, we are confident that the coming year will be an exciting one, and one where it is our goal that by mid-2013 at least one emergency service or disaster response organisation will have some aspect of Serval technology ready for deployment to support them in their future operational exercises.

Thursday, July 5, 2012

Sneak-Peak of Encrypted Calls, Even on Slow Android Phones

Just a quick post to show the latest development code of the Serval Mesh running an encrypted phone call on some low-end handsets, and keeping comfortably below 50% CPU:

As well as encryption, this call is being carried by the Serval Overlay Mesh, and is all native VoMP and MDP, and contains no SIP, RTP or anything IP dependent.  So this demonstrates the feasibility of our Overlay Mesh architecture as it might be used for phones with a built-in Arduino or similar with ISM-band UHF radio modules to support longer-range mesh links.

Some of the output from top while in the call is below.

User 27%, System 25%, IOW 0%, IRQ 2%
User 46 + Nice 43 + Sys 85 + Idle 147 + IOW 0 + IRQ 0 + SIRQ 7 = 328

  PID CPU% S  #THR     VSS     RSS PCY UID      Name
 2627  21% R     1  10336K   4544K  bg app_72
 2537  11% S    21 140628K  23560K  fg app_72   org.servalproject
  135   8% S    60 197008K  28672K  fg system   system_server
 2600   7% R     1    904K    420K  fg shell    top
 2611   6% S     1      0K      0K unk root     dhd_dpc
   54   0% S     1      0K      0K  fg root     gs_wq
    4   0% S     1      0K      0K  fg root     events/0
 1702   0% S    12 129616K  22368K  bg app_19
   76   0% S    12  17188K   1340K  fg root     /system/bin/rild
   11   0% S     1      0K      0K  fg root     kseriod

User 31%, System 21%, IOW 0%, IRQ 2%
User 63 + Nice 43 + Sys 73 + Idle 146 + IOW 0 + IRQ 0 + SIRQ 8 = 333

  PID CPU% S  #THR     VSS     RSS PCY UID      Name
 2627  19% R     1  10532K   4740K  bg app_72
 2537  18% S    21 137556K  23600K  fg app_72   org.servalproject
 2600   7% R     1    904K    420K  fg shell    top
 2611   5% S     1      0K      0K unk root     dhd_dpc
  135   1% S    60 197008K  28672K  fg system   system_server
 1824   0% S    10 123752K  21508K  bg app_33   android.process.acore
   54   0% S     1      0K      0K  fg root     gs_wq
    8   0% S     1      0K      0K  fg root     sync_supers
    9   0% S     1      0K      0K  fg root     bdi-default
   10   0% S     1      0K      0K  fg root     kblockd/0

User 31%, System 24%, IOW 0%, IRQ 0%
User 64 + Nice 39 + Sys 79 + Idle 145 + IOW 0 + IRQ 0 + SIRQ 1 = 328

  PID CPU% S  #THR     VSS     RSS PCY UID      Name
 2627  18% R     1  10728K   4936K  bg app_72
 2537  14% S    21 137524K  23416K  fg app_72   org.servalproject
 2600   7% R     1    904K    420K  fg shell    top
 2611   5% S     1      0K      0K unk root     dhd_dpc
 1859   4% S    12 131092K  25252K  bg app_18   com.huawei.launcher2
  135   3% S    60 197008K  28672K  fg system   system_server
   54   1% S     1      0K      0K  fg root     gs_wq
  227   0% S     8 112696K  12084K  fg app_44   com.nuance.nmc.sihome
    9   0% S     1      0K      0K  fg root     bdi-default
   10   0% S     1      0K      0K  fg root     kblockd/0

User 26%, System 23%, IOW 0%, IRQ 0%
User 43 + Nice 45 + Sys 76 + Idle 161 + IOW 0 + IRQ 0 + SIRQ 2 = 327

  PID CPU% S  #THR     VSS     RSS PCY UID      Name
 2627  22% R     1  10916K   5124K  bg app_72
 2537  14% S    21 137524K  23484K  fg app_72   org.servalproject
 2600   6% R     1    904K    420K  fg shell    top
 2611   4% S     1      0K      0K unk root     dhd_dpc
  135   1% S    60 197008K  28672K  fg system   system_server
   54   1% S     1      0K      0K  fg root     gs_wq
    7   0% S     1      0K      0K  fg root     suspend
    8   0% S     1      0K      0K  fg root     sync_supers
    9   0% S     1      0K      0K  fg root     bdi-default
   10   0% S     1      0K      0K  fg root     kblockd/0

User 29%, System 23%, IOW 0%, IRQ 0%
User 55 + Nice 41 + Sys 78 + Idle 150 + IOW 0 + IRQ 0 + SIRQ 3 = 327

  PID CPU% S  #THR     VSS     RSS PCY UID      Name
 2627  19% R     1  11112K   5320K  bg app_72
 2537  18% S    21 137524K  23528K  fg app_72   org.servalproject
 2611   6% S     1      0K      0K unk root     dhd_dpc
 2600   6% R     1    904K    420K  fg shell    top
  135   1% S    60 197008K  28672K  fg system   system_server
   54   0% S     1      0K      0K  fg root     gs_wq
 1859   0% S    12 131092K  25236K  bg app_18   com.huawei.launcher2
    4   0% S     1      0K      0K  fg root     events/0
   10   0% S     1      0K      0K  fg root     kblockd/0
   11   0% S     1      0K      0K  fg root     kseriod

User 27%, System 22%, IOW 0%, IRQ 1%
User 41 + Nice 49 + Sys 73 + Idle 160 + IOW 0 + IRQ 0 + SIRQ 5 = 328

  PID CPU% S  #THR     VSS     RSS PCY UID      Name
 2627  20% R     1  11308K   5516K  bg app_72
 2537  16% S    21 137524K  23396K  fg app_72   org.servalproject
 2600   6% R     1    904K    420K  fg shell    top
 2611   6% S     1      0K      0K unk root     dhd_dpc
  135   0% S    60 197008K  28672K  fg system   system_server
    6   0% S     1      0K      0K  fg root     async/mgr
    7   0% S     1      0K      0K  fg root     suspend
    8   0% S     1      0K      0K  fg root     sync_supers
    9   0% S     1      0K      0K  fg root     bdi-default
   10   0% S     1      0K      0K  fg root     kblockd/0

Wednesday, June 27, 2012

Screenshots from Serval Nightly Builds

Hi all,

Here are a few screenshots from the nightly builds of what will likely become Serval Mesh 0.90 in a couple of months time:
The main display when running the mesh.  The number at the bottom is your mesh telephone number.  If you provide a display name, it also shows there. 

This is where you setup your mesh telephone number and provide your name, to make it easier for people to find you on the mesh.

The "Contacts" button on the main display gives you the choice of showing who is currently on the mesh, or showing who is in your Android contacts.  The Android contacts can now have mesh contact details, to make it easy to call or text via the mesh from the Android contacts.

Showing the current contact list gives you the details of any phones on the mesh, as well as their  secure identifier (SID).  You can call, text, or add them to your Android contact list.  Names are displayed instead of numbers when available.  The "Broadcast/Everyone" option lets you send text messages to everyone on the mesh, as a simple kind of group chat or micro-blogging service.  This will be refined into an off-grid Twitter-like system in a future release.

Serval Project Quarterly Update 2012Q2

The last quarter has been quite an exciting one from our perspective, although much of the excitement has not been externally visible.  So here are some of the highlights that you may or may not already be aware of.

Version 0.08 Released

The most notable visible progress has been the release today (27 June 2012) of version 0.08 of Serval Mesh to the Android Market / Google Play.  This is primarily a bug-fix and minor-enhancement release while we finish drawing together a whole pile of work that has been going on behind-the-scenes that will show up in the next version, version 0.90.  The jump in version numbers should give you a clue as to how significant we think the next version will be, so lets have a look at the contrast and what is being planned.

Preparations for Version 0.90 - Switching From Architecting To Integration

Version 0.08 is a direct descendent of the initial proof-of-concept that launched the Serval Project back in mid-2010.  The bulk of the work in this past quarter has been preparing the reengineered "production" functionality of Serval.  In the last week or so we have reached the point where the bulk of effort is now going into integration of the various components, shaking out the bugs and finding the outstanding tasks that need to be done to make it all work seamlessly together.  This is a very encouraging and exciting stage for the team as we see the hard work over the past year or so come together to make something that we think will be compellingly useful for many people.

To get an idea of the scope of work that has been undertaken, let us summarise a number of the properties of version 0.08 (the most recent proof-of-concept derived release), and then compare this with the reengineered work.  First, version 0.08:

  • It requires root permissions to operate, because it needs ad-hoc WiFi to provide end-to-end network paths for the mesh routing protocols. 
  • It relies on BATMAN or OLSRd for mesh routing over ad-hoc WiFi. 
  • It has no encryption or authentication of calls.
  • It includes a complete installation of Asterisk to do the PBX/VoIP call routing. 
  • It includes an entire SIP client that talks to the Asterisk installation.  
  • It can only operate on IP networks. 
  • It has only a prototype of the Rhizome store-and-forward mesh file sharing service. 
  • It relies on 3rd-party applications to send or receive MeshMS (SMS) messages over the mesh.
  • It has a rather awkward user interface.
  • It has no APIs for interaction with other applications.

In contrast, Version 0.90 will include a pile of reimplemented and new functionality that will make for a  totally transformed product and experience:

  • It will not require root permissions, removing the single greatest barrier to adoption.
  • It will include its' own mesh routing engine that can operate over access-point and client mode WiFi, and deliver MeshMS and files even under highly partitioned network conditions.
  • It will offer robust end-to-end encryption of voice, MeshMS and, later, of files over the mesh. A later version will also include simple and effective protection against man-in-the-middle attacks.
  • It will include its own VoIP over Mesh protocol (VoMP), that is light weight and avoids the need to include Asterisk and a SIP client.  This has allowed us to shave 60% off the application size (about 2MB instead of 5MB), and increase responsiveness and speed significantly, even while adding in end-to-end encryption.
  • It will be able to use non-IP transports, e.g., packet radio, carrier pigeons carrying memory sticks and almost any other digital data carrier to synchronise data between meshes.
  • It will include the new low-latency and auto-prioritising reimplementation of the Rhizome store-and-forward data distribution service.
  • It includes it's own MeshMS client, removing the need for external SMS handling applications: one APK provides all services.
  • It will include a completely redesigned and reimplemented user-interface.
  • It will include APIs to allow interaction with the mesh, and use of mesh services by other applications.
All of these features are nearing completion and being integrated ready for release as version 0.90 sometime in the coming quarter.  Significant and intense progress has been made, and the various features are now beginning to come together, and the work is increasingly focussing on integration and whole-of-system behaviour, rather than on completing the individual components.

Together, they constitute a useful product, one that we will be able to demonstrate to various potential partners and even paying customers who are looking for custom mesh services, making Serval well and away the clear leader in mesh telephony.

Continued Interaction With New Zealand Red Cross

Following our participation as observers at KiwiEx 2012, we have continued to nurture and develop our relationship with the New Zealand Red Cross IT&Telecommunications Emergency Response Unit (IT&T ERU).  As a result we are addressing the specific requirements and refinements that they have identified as being necessary to make Serval useful for themselves and the broader humanitarian and emergency response sector.

Presentation to UN Working Group on Emergency Telecommunications (UN WGET)

During the past quarter our existing relationship with New Zealand Red Cross gave us the opportunity to present not only to NZ Red Cross, but also to IT representatives from the Internatational Federation of the Red Cross/Crescent (IFRC), Internation Committee of the Red Cross/Crescent (ICRC), the World Health Organisation (UN WHO), UNHCR and several other major international humanitarian and emergency response organisations.

This was a tremendously positive day, with considerable interest expressed in what we are doing, and how it might be able to help meet various needs among those organisations. As a result of that meeting we are anticipating further engagement with those organisations and WGET as a whole, and are preparing to submit a proposal to them relating to field data collection.

On-Going Work With OTI/Commotion Project

The other major activity during the quarter has been continuing the work on integrating Serval with the Open Technology Initiative's Commotion project.  This will allow OpenBTS-based portable GSM cellular networks to interoperate with Serval mesh telephones in a seamless manner.  The first tangible result of this will be the use of Serval's Distributed Numbering Architecture (Serval DNA) to allow meshed OpenBTS units to route calls amongst themselves.  This should be functional within the next few weeks.

Tuesday, June 26, 2012

Serval Mesh/BatPhone 0.08 Release

A release of the 0.08 version of Serval Mesh is going up on the Android Market as we speak (if you still see 0.07 on the market, please be patient -- it can take a few hours for Google to update the available version).

Selected features and bug fixes include:

  • Rhizome store and forward transport.
    • Share files, share videos, and send text messages to people who aren’t directly reachable at the moment. This should be considered an early preview, there’s plenty of work still to go. (text messaging currently requires WebSMS / SMSDroid to use as the front end).

  • Improved peer list
    • Now with name resolution from your Android contacts, real-time display of network reach-ability information, and quick link to open WebSMS (if installed) for text message entry.

  • Smaller APK file size
    • APK file now 4.8MB, down from 5.8MB for 0.07.
  • Improved Handset Support
    • Added Galaxy Tab.

  • Bug Fixes
    • Reduced prompting for root access, better detection of failures.
    • Keep a foreground service running to prevent our process being accidentally killed.
    • Fixed control of hotspot/access-point mode on Android 4.0+ (ICS).
More information is available at the Bug Tracker and GitHub.

Version 0.08 is very likely to be the last release before we switch to the overlay mesh code, which brings in very strong security, will have a totally revamped user interface, will not require any external applications for sending and receiving mesh SMS messages, and will mean that we will not longer need root access on a phone for it to join a mesh.  

More on that when the next version is ready for release.

Holodecks For Aged Care Facilities?

It is the little things, the things that don't matter, that are really the big things, and the things that matter.  

This is doubly true if you are unable to live in your own home any longer, and are dependent on supported care of some sort.  

Old Woman Feeding Birds
(Image by soylentgreen23

While often necessary, such care risks removing all the things that really matter in life. I still remember when my own grandmother was old and frail, and had to move into supported care.  For 83 years she was used to a life outdoors, with the fresh air and sunshine.  What she wanted most was to be able to open a window and let the sunshine in, or potter outside in the garden, or smuggle more cheese cubes to the stray cats that used to visit the nursing home.

But she basically had to live in a very comfortable hotel room, but which she found very oppressive given her life experience.  Apart from being part of the underground railroad for the feline dairy supply, I still remember that the last "good day" that she had was when we busted her out for a day and took her blackberry picking in the hills, something that was a regular part of her independent life. It wasn't "medically sensible" and it wasn't "necessary", but gee whiz, it really mattered to her, and that's what matters.

Since then I have been thinking on and off about how to break down the feeling of being trapped and encased in an institution, so that we can rehumanise and reconnect older people's lives with the world around them.

I have been talking with some people in health care about making some sort of holodeck for residential care facilities to help improve their resident's quality of life.  

It seems that the technology is there to make something fairly affordable, that would allow some interactivity, and sufficient suspension of disbelief that it might be worth exploring.

The initial model I am thinking of is one of having some cameras at a nice location, most likely a sea-side spot somewhere.  These record video and audio in several directions so that a view of the scene can be projected into a "holodeck" that provides an immersive sense of being there.  We might even use fans to generate wind with matched speed and direction as is actually occurring at the location. I am sure the Eurovision Clearance Store must have plenty.

Rather than a loop that fails to suspend disbelief, having a real live feed makes the experience much richer, and also allows for more interesting interactivity.  

First, we can pipe video and sound both directions, so that someone approaching the camera site would see an old person in a room listening to the waves, who might notice them as they approach, and then they could have a chat if they wished.  

Second, the natural cadence of the scene with less interesting bits and more interesting bits adds the variety that makes life worthwhile.  Showing once-in-a-century shots like blue whales swallowing sharks, and the same amazing purple sunset are counterproductive, because they are overstimulating.  It is the subtleness and realness that matter, and that make the connection believable.

A fun interactivity booster would be to add a seagull food launching device, that fired (nutritionally balanced) seagull food whenever the person threw a (possibly synthetic) chip at the wall, so that they could experience the interactive pleasure of feeding seagulls and watching them wheel and crane overhead, and catch the specially
formulated seagull food mid-flight, and generally enjoy a sense of escape from their institution.

Finding a way to synthesise sea-side smell would also add tremendously, because smell is such an evoker of memories.  Indeed, the smell centre of our brains is the most directly wired sense, and can cause such strong and immediate reactions.

Obviously these holodecks could be setup in all sorts of places, and with a variety of location appropriate interactivity diverse, e.g., feeding ducks by a pond, or a sitting on a "digital park bench" to feed pigeons and talk to people who sit next to them in the real world.  They could be moved around, as well.

Ultimately, they may provide a key part of the quality of life of people in residential care, as well as to help stop them being a population who are hidden inside institutional walls, invisible to a society who would otherwise be willing to say hello, and help them maintain some connection with outside society.

It seems to me that a prototype of this could be created fairly easily and without excessive cost, and that there are probably all the skills in a typical geek/maker community necessary to make it happen.  

I don't have funds for the project now, or the time to do it all myself, but if we made a prototype, I think we might be in a good position to secure funds, whether from governments, arts councils or various other sources to make more and/or better ones to help more people.

Anyone interested in seeing how much fun and how rewarding this could be, or know anyone who might be?

Wednesday, June 6, 2012

No Such Thing As Free Lunch, Unless You Are A Social Entrepreneur

Social entrepreneurship has many definitions.  My working definition is:

"A Social Entrepreneur is someone who wants to make a positive change in the world, and realises that they still need to pay for lunch while doing so."

This differs from the capitalist who sees the enterprise as a means to buy lunch, and the philanthropist who is lucky enough to have the means to buy lunch without having to earn any more money.

So why all the talk about lunches?  

There is a saying that to "cut someone else's lunch" means to take something out from under them, usually work, e.g., to purposely under-bid on work to take it away from someone else who has a fair entitlement to it.  Here's an example that I found in a few minutes of internet trawling to give you an idea of how it is used. (It can also mean to try to hit onto someone else's partner, but that's another story.  Here in Australia both meanings apply).

So if you cut their lunch for them, you are doing them some kind of disservice, by taking something that was theirs to do or to enjoy or generally derive benefit from.  

This is particularly true for the capitalist for whom buying the lunch is what it is all about: if they cannot derive financial or status benefit from cutting their own lunch, then they have lost something very tangible. Anger or grief may then naturally follow.

But for the philanthropist and social entrepreneur things are different.  It is the improving of the human condition that is their desire.  

For them, it is a gift for someone to cut their lunch, it really is a free lunch, and then some.

Consider for a moment if some upstart discovered a 100% effective and affordable vaccine for malaria.  This would be cutting Bill and Melinda Gate's lunch, since that is one of the great things that they are working on through their foundation.  

But I have little doubt when I say that if that were to occur the Gates' would be jubilant with celebration, because someone has gone to the effort of cutting their lunch, so now they can move on to the next thing

So it is for all social entrepreneurs if they think the matter through: to be out competed in improving the human condition is to receive the gift of days that were otherwise required to work on that venture: they can now move onto the next thing, and celebrate that what they set out to achieve has been accomplished.

The Universal Bug Tracker For Society

I have a problem. I have too many ideas for things that should be made or fixed to make the world a better place.

 Let me explain a little. I run the Serval Project, making mobile telecommunications available in many situations where it is not currently possible. In leading that project I have discovered that there are some serious problems with WiFi for supporting ad-hoc network that it would be great to have fixed.

Then I also discovered that it would be really great to make mobile phones with a built-in Arduino or similar micro-controller and accessible hardware port so that people can innovate with mobile hardware just like they do with mobile software. This could be used to make all sorts of things, from powerful yet cheap environmental monitoring systems, to supporting long-range mobile mesh networks, to creating really low-cost medical monitoring devices (for example, a pulse-oximetry machine is really just four LEDs plus some signal processing that a phone could easily provide).

This is already too much for me to do right now.  But I have other ideas queued up, and that I come up with over time.

For example, since being inspired by Prof. David Powers during my undergraduate degree, I have been convinced that we need to make laws machine-readable. This makes a lot of sense, since the whole idea of legal language is to be clear and precise. In the past legalese was the best we had to express the logic part of laws, but now we have computer languages and compilers that are so precise that it is almost annoying, but more importantly, can help us to visualise and transform legal logic into other equivalent forms that allows the intent and effect of the laws to be checked before being proclaimed.

With some careful construction, we could make a LawCompiler 1.0 that lets us do this kind of thing. Much would be possible with just a combination of definitions and logic blocks. For example, to work out if someone could legally work in Australia, we might have a logic block like:
FUNCTION CanLegallyWorkInAustralia BEGIN
 IF IsAustralianCitizen OR IsNewZealandCitizen OR HoldsValidWorkVisa THEN
  RETURN true
  RETURN false
Then all that needs to be done is to recurse back through the referenced terms in the logic block and define them also. The ideal would be that terms are defined as logic blocks themselves, but at some point there is probably a need to define some in legal terms, so you simply have a definition, e.g., we might cheat in the above and define IsNewZealandCitizen like:
 “A person shall be considered a citizen of New Zealand if  they are not a citizen of Australia, and if they currently hold citizenship in the nation of New Zealand.”
But eventually we could do things like:
IMPORT IsNewZealandCitizen FROM  NewZealand.CitizenshipAct.1992;
This would allow a flexible, bottom-up approach to harmonising laws between jurisdictions where it makes sense (some distinction between dynamic versus static binding of definitions would be necessary). For example, states or counties could reference common dog-ownership regulations, or countries in the European Union could harmonise laws by referencing definitions created by the EU, and such harmonisations could be made progressively.

The compilable laws would be no less readable than ones in legalese by the average person on the street, and would have the advantage of being subject to precise interpretation, irrespective of the human languages involved, thus aiding translation and consistency in jurisdictions where laws have versions in multiple languages. To aid interpretation, or to help find bugs in laws, such logical definitions of laws can be transformed, e.g., into a truth table, that allows for checking that the law does not create any strange corner cases, which is a very common problem in laws of any significant complexity. For our legality of working test above, the truth table would resolve to something like:


By definition each of the lines in the truth table are mutually exclusive, and so it becomes fairly easy to work out what will happen in any given situation. Of course for realistic laws, there may be dozens of input factors, and so the truth-table may grow very large, but that can always be avoided by creating intermediate definitions for common cases. This also helps promote the cleaning up of the logic in laws instead of perpetually tacking bits on the end that make the entire thing incomprehensible. Income tax laws are a good example of this. By being able to compare truth-tables before and after a patch, it becomes possible to know with complete certainty, that the patch to the law (or cleanup of the law) has not changed the meaning of the law in any unexpected way.

Anyway, I digress greatly, but that is perhaps the point. I need a place to capture all these ideas, so that they can be vetted, prioritised and actioned, either by myself or someone else. Similarly, it would be great to capture everyone else's ideas, and basically assemble a Universal Bug Tracker For Society (UBT4S)

This would make it easier for me to sleep at night, knowing that the ideas are captured. It would also allow me to be much more effective by being able to more easily focus on exactly one bug at a time, and to record any progress or thoughts relating to others. But again, I suspect that the impact will actually be much greater from other people entering the feature requests and bugs of society that they think of or notice.

The UBT4S also makes it easy for people who are not plagued by new ideas to join in the effort, but who want to make a positive impact in the world: They can simply go to the UBT4S, browse the bugs and feature requests, maybe vote some up or down, add some notes, or, hopefully, assign one to themselves and do some work on it.

The underlying philosophy that makes the UBT4S make sense is the realisation that if you are a social entrepreneur having someone else cut your lunch by doing something you had planned to gives you a free lunch in the form of releasing you to pursue other innovations. I'll write a blog post on this competition-is-a-gift aspect of social entrepreneurship soon.

But right now, this is what I am going to do: I am going to register and setup a bug tracker there, that will be open to anyone to register and contribute to. I will pre-load it with some bugs and feature requests for society that I have in mind (including those above).

I will also lay out some rules for the UBT4S. These rules will be subject to the UBT4S itself, and so if you don't like them, then please submit an issue that describes the problem and how they can be improved.

This is a very important point, because I don't want the UBT4S to be a whinge board about all that is wrong with society. I also don't want it to be a place where people say that country X needs party Y in power. The political domain is already quite saturated, and not a fun place to operate for the most part. 

The UBT4S, on the other hand, is a place where tools and personal-action is the approach. Think of it as a meta-project around various various existing and yet-to-exist open-software, open-hardware and life-hacking projects that has “universal peace and happiness” as its' goal (which I have purposely not defined), and then identifies tools that can be used to edge closer to that.

I immediately recognise that this approach has limitations, but then so does Newtonian Physics, but that doesn't stop us using non-relativistic rulers to measure how tall our kids are, and nor should the fact that the UBT4S has natural limitations prevent us from achieving as much universal peace and happiness as we can using that tool.

So now I throw the challenge out to you: visit, add bugs, issues and feature requests.  Comment on existing issues, and maybe start Wiki pages to begin marshalling resources for them. If you are part of a project that is providing a solution (or part of a solution) to an issue, then make a note of that in the tracker. That way people who want to help in that particular area can find the right projects to join, donate to or otherwise help.

I look forward to seeing you at the UBT4S.

(Also if anyone has a better idea than using Google Code, I'm all ears.  Add it as an issue to the UBT4S, and we can work on fixing it.)