[mesh-talk] Serval and $9 mesh router

[Marc Juul]

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-computer/

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_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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sudoroom.org/pipermail/mesh-talk/attachments/20150509/d90d5597/attachment.html>