[Commotion-dev] Thoughts on secondary apps

[Tim Yardley]

I'd suggest the standard KISS approach initially.  Everything Erich
says here is valid though.

To toss out this idea for priorities...

1) Get standard oslr mesh and tor running on the firmware.
2) Get default mesh params so that these devices are turned on and ready to go.
3) Get dashboard interface working that shows you the status of the
devices (how many mesh nodes are connected? Do I have an uplink?)
4) Get easily-reconfigured mesh param interface up.
5) Get custom caching services up.
6) Get some security (certificates perhaps) for mesh nodes and work
that into the interface for approval.

On Tue, Feb 1, 2011 at 12:51 AM, Erich Heine <sophacles at gmail.com> wrote:
> Hi all,
> I've been doing some thinking on this whole secondary apps thing. Basically,
> the main idea is to have a few easy apps, and an openwrt distro that can be
> put on lots of cheap boxes to create a decent mesh. If lucky, some few main
> internet uplinks can be organized for information access to and from the
> outside world.  Also extremely relevant: the whole point of these networks
> is to subvert governments. All of this leads to some really crazy
> constraints and considerations.
> First of all, consider use cases, which seem to fall naturally into some
> sort of priority scheme. Here is how i see it, which is by no means a
> complete, or even accurate list, but we gotta start somewhere
> 1. Organizing the revolution (or resistance or protests or whatnot) -- this
> will probably be the most important use case for those hosting the network.
> They need to communicate and make sure things are properly organized. If i
> were in this situation, I would consider this the utmost importance as there
> are very serious consequences (prison, death, etc) attached. This needs to
> happen.
> 2a. Keeping the world informed -- protests and such are messy affairs. Its
> usually best to be very public about all happenings, particularly when your
> opponent is the government. Public and international, as you want things to
> remain somewhat tame, and the easiest way to do this has historically have
> "the whole world is watching" situations (well better than the alternative
> :( ).
> 2b. Keeping up on the rest of the word: Is the UN sending in blue helmets?
> Will we get help coming in and when? Are we getting the right message out
> about our goals?
> 3. Tell my family I am alive. People will want to share this info with
> family and friends abroad.
> So on top of these use cases we have some weird constraints here:
> * Limited Internet connectivity. It's like the olden days but worse -- fast
> LAN super slow WAN. Further that WAN link is probably pretty sketchy and
> down and up a lot.
> * Honest to goodness hop-count issues, and other weirdnesses from running
> lots of traffic through small boxes.
> * Trust issues like woah -- social trust issues between/about various
> groups, mesh networks seem tailor made for MiTM situations, canonical naming
> and other issues go out the window.
> * Infrastructure setup issues -- even if we get a packet network up and
> running on meshed devices, there needs to be a bunch of local services set
> up to deal with the fact that 1. no one can reach standard infrastructure
> reasonable (see the limited connectivity issues) and 2. many of the local
> language services are probably run on servers that can no longer talk to the
> network, and probably can't reasonably be expected to jump on the mesh.
> Ok so there is a weird situation here! Honestly a huge chunk of it sounds
> like a job for freenet -- otherwise we just end up cobbling something
> together out of git, ssh, pgp. Other things to consider too tho:
> * Batching communications for low priority transmission. Email can work this
> way. Or we could do something a bit more sophisticated.
> * Key parties: seriously, this network and situation almost demands giving
> everyone a key and good key ring apps. Otherwise this whole thing is fairly
> easily subvertable. Key signing should be trivial, as should web-of-trust
> stuff. smart-phones can really help here, a nice android app devoted to key
> exchanges really makes the whole thing reasonable.
> * user education -- everything above needs to be teachable to the users in
> some form, quickly and with minimal effort, because really, there are bigger
> things afoot and the easier it is to get people ready to go, the better.
> Things that sound like good ideas to consider, but probably are just easier
> to solve socially:
> * deciding what gets out over the uplink: really this will come down to the
> uplink operator anyway, so there is no point trying to enforce it...
> * factional disputes, trust of leaders, who gets the best info out: this
> problem has existed far longer than the internet, the real problem is that
> social upheaval is pretty much by definition messy, and as such there is no
> fix by tech.
> Anyway... My little thought experiment turned into a total brain dump. Hope
> there is enough here to start a good discussion on this topic, and maybe
> consider setting an agenda on it.
> Regards,
> Erich
> (sophacles in irc)
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> http://lists.chambana.net/mailman/listinfo/commotion-dev
>
>