[mesh-talk] Serval and $9 mesh router

Just wanted to ask if people are up for a quick round of testing Serval after this Tuesday's meeting. If you're up for it, make sure to bring your rooted android device for the meeting and pre-install Serval if you have time! Then we can spread out and see how far Serval reaches and decide whether it's really worth it. Oh, and if you didn't already see it, there's a $9 open hardware wifi linux board coming out that's made by a small company a few blocks from where I live(!): https://www.kickstarter.com/projects/1598272670/chip-the-worlds-first-9-com… I tweeted at them to ask what the wifi chip is but no reply so far. I can make out a RealTek logo though. We should invite them over for BBQ or something. They have the Shenzhen hookups. If the power requirements are low enough and the wifi chip isn't too sucky (also allwinner chips don't have a great rep) then this could be interesting since it'd be capable of doing what a garden sensor node does, but also run babel and web apps. The USB stack is sure to suck though and no Ethernet + shitty on-board wifi antenna so this will never be a viable home or extender node. --- begin: Some thoughts on Serval 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_r… ) 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