I don't feel like the wifi meshing part of Serval is likely to be useful (but maybe I'm wrong). Mostly because it doesn't actually work unless you have a rooted and compatible device, which probably excludes the vast majority of folk. Then there's the limited range of smartphone wifi and the extra battery usage for relaying.

I'm not sure I fully understand Serval's Mesh Datagram Protocol nor their mesh routing protocol, but if my mental model is correct then MDP provides security and some of the functionality of IP (addressing) and they don't have a mesh routing protocol but resort to ad-hoc wifi broadcast ( http://developer.servalproject.org/dokuwiki/doku.php?id=content:tech:mesh_routing ) though they plan to implement their own protocol that relies on MDP. They're basically re-implementing not just mesh routing but also IP and UDP/TCP. Sounds ludicrously ambitious for such a small team if you ask me.

The voice calling sounds nice. They basically implemented a minimal voice protocol from scratch that is optimized for mobile meshing (though without mesh routing I'm not sure how useful it is and it relies on MDP for security). The mapping sounds cool, but not yet included in a stable release. The Rhizome/MeshMS system seems useful, (it looks like the same kind of protocol as scuttlebutt, not sure what the protocol is nor how encryption works). Bluetooth as an alternate transport is really great, but is not included in any stable version yet.

The GUI is almost non-existant, and parts of it seem likely to become unusable if any number of people are actively using the mesh. That's ok. It's early experimental software.

It looks like the actual useful parts of serval will be the Rhizome/MeshMS/Mapping over the upcoming bluetooth transport. This is of course a non-real-time type of communication where data is stored and forwarded as people walk around and phones sync as they come within range. For real-time communications I think it's probably better to rely on something like sudo mesh and then only allow calls when a you're near an access point.

btw, I ran into an Android app that does Rhizome/MeshMS style store and forward, but which has an unfortunate (but probably easily removable) integration with twitter:

  https://code.google.com/p/twimight/

Honestly I think Serval has fallen into the trap of inventing everything themselves and becoming their own island of "stuff that we make only work with our stuff".

The useful parts of Serval should probably just be separate apps that work equally well on mesh and non-mesh infrastructures.

Since RedPhone already exists it might be better to add multicast-based signalling (right now a server is required) and then be able to use it on a Mesh. We'd need a way for phones to call someone directly based on their pubkey hash instead of their phone number. A simple and reliable version of that could be simply entering the pubkey, but a better version could be registering RedPhone to handle specific URLs and then adding the ability to show a QR code of your own pubkey which encodes such a URL. This exchange would require that everyone also has a QR-code scanning app, but there is a nice open source one available already. The fallback would be manually entering the pubkey hash. The major problem would be that Android push notifications don't work without the Google Cloud. MEH! Battery usage might be a problem since a background service would have to actively parse all incoming RedPhone multicast messages.

If I were to write something like Rhizome/MeshMS/Mapping then I'd grab the bluetooth auto-disovery and auto-connect code from twimight, then I'd use secure-scuttlebutt via jxcore for non-realtime communication (might require a bit of hacking to get leveldb talking to the js code). For maps the mapsforge library already does Open Streetmap offline vector-based mapping.

--

marc/juul