I didn&#39;t read your entire email, sorry. but i absolutely agree store-and-forward is very important and interesting thing to investigate in the context of internet freedom. we could do an interesting experiment to set up a revival of usenet over either WoT or wifi mesh. if we could make the experiment work that would be a really cool result. putting usenet into the freedombox would probably be easy, and definitely noone could say we&#39;re reinventing the wheel (although, maybe rediscovering a forgotten wheel)<br>
<br><div class="gmail_quote">On Tue, Mar 1, 2011 at 1:02 AM, Tracy Reed <span dir="ltr">&lt;<a href="mailto:treed@ultraviolet.org">treed@ultraviolet.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello all,<br>
So far it appears that everyone is focused on TCP oriented connection<br>
protocols which require the freedom box to have a live Internet<br>
connection, perhaps via mesh. That would seem to me to be missing what I<br>
see as the whole point of Freedombox entirely.<br>
I, too, have been thinking people need some small and inexpensive device<br>
which people can use to communicate and get freedom.  I was happy to<br>
hear of the foundation of this project.<br>
The first thing evil regimes always seem to do is to turn off the<br>
Internet access and censor communications in general. I keep asking<br>
myself, &quot;How did people communicate electronically before broadband<br>
Internet or even PPP dial-up enabled the always-on connections which<br>
allowed the web to grow?&quot; The answer is store and forward message<br>
passing systems: UUCP in the case of pre-Internet communications.<br>
More than anything people need a way to ship around messages such as<br>
tweets, emails, IMs, and smallish files. They need to be able to send<br>
around simple news and activity coordination items. They don&#39;t need<br>
flash and ajax and graphic heavy webpages. That is for marketing, not<br>
freedom-giving information exchange.<br>
Wild stream of consciousness brainstorming follows:<br>
* Allowing transmission of messages world-wide in the face of active<br>
* Not requiring a dedicated Internet connection<br>
* Encrypted<br>
* Hard to detect<br>
* Location-aware (for routing purposes)<br>
* Provide very basic communications abilities. This is an improvement<br>
  when people have no ability to communicate at all.<br>
Dedicated freedombox devices<br>
Mobile phones/apps<br>
Primarily wifi with wired and 3G Internet gateways as short-cuts via<br>
systems that support it.<br>
How it works:<br>
There would be a standard messaging protocol similar to UUCP or AMQP or<br>
SMTP or something (whatever best fits whatever the ultimate system is to<br>
be). Messages (be they files, SMS, email, whatever) would be fit into<br>
this protocol.<br>
The whole idea is to get a message from a place that doesn&#39;t have an<br>
Internet connection (presumably because an evil regime has destroyed the<br>
economy so there is no infrastructure or is actively prohibiting net<br>
connections) to a place where there is one so that the message can be<br>
delivered and vice versa.<br>
It would implement a protocol...call it (for lack of anything better)<br>
Freedom Protocol (FP).<br>
It would have a GPS or be able to be fed its lat/long by a passing GPS<br>
enabled device communicating to it via wi-fi (such as a mobile phone<br>
since many of them have GPS and wi-fi in them now). Accuracy isn&#39;t<br>
important. We just want to know what general part of the world we are<br>
in. Accurate to within 10km would probably even be good enough.<br>
Let&#39;s say that I am a revolutionary who wants to send out a message to<br>
another local revolutionary. I can encrypt a message to his key or send<br>
in the clear if I don&#39;t have it or am not capable. I have a mobile phone<br>
with wifi and GPS.<br>
Like all FP capable devices, it knows:<br>
* Where we are likely located (via onboard GPS or because someone told<br>
  it where we were when it last communicated with a GPS enabled FP<br>
  speaking device)<br>
* Where I generally travel (doesn&#39;t keep specifics on lat/long, just a<br>
  probability distribution because I don&#39;t want my phone to tattle on my<br>
  exact movements, especially if it is captured).<br>
* What the probability of my coming into contact with a wired uplink is<br>
  (think of this like NTP: call it stratum 1 probability)<br>
* What the probability of my coming into contact with another FP device<br>
  and its probability of coming into contact with a wired link (stratum<br>
  2 probability etc)<br>
* It also keeps track of the probability of communicating to a<br>
  particular part of the world of each of the other FP speaking devices<br>
  it talks to. This is for routing messages back to the non-connected<br>
* Wifi bandwidth is plentiful but not unlimited while we have it but<br>
  connections are somewhat rare.<br>
* Connections to the wired Internet from which everything can be reached<br>
  are rarer.<br>
* Opportunities to transmit/pass along may be limited, especially at<br>
* Message space is limited<br>
My device wants to hand off this message as soon as possible. They find<br>
each other via wifi broadcasts. Maybe the above probability info is what<br>
we broadcast if we can fit it all in a packet.<br>
We want to find other devices and offload our message(s) quickly. We can<br>
keep a history of what location and stratum probability distributions we<br>
typically see. From this we can decide how desperate we are to offload a<br>
message and to whom. We should probably hand off the message to the very<br>
first device we see just to get it out there, then perhaps more<br>
judiciously later for either a fixed amount of time (TTL?) or until we<br>
get a reply.<br>
We come into contact with another device implementing FP protocol. It<br>
could be mobile (an app running on a GPS/wifi enabled mobile phone), it<br>
could be fixed (a wall wart discretely hidden away somewhere). We send<br>
it our message. It weighs the likelyhood that it will be able to deliver<br>
the message vs available storage capacity. It may drop an old message, a<br>
message which has already been passed along a number of times or reached<br>
its (potentially long) TTL, or whatever message it calculates it is<br>
least likely to be able to deliver (which might even be ours).<br>
You can transmit an awful lot of SMS style text messages quickly via<br>
wifi. We want to be able to get this done in mere seconds in case we are<br>
passing by quickly such as in a car.<br>
Our message gets passed along in this way hopefully always getting<br>
closer to its recipient whose location we specified in general and<br>
perhaps specifically by encrypting to his private key.<br>
Or perhaps we want to send a message to the free Internet-enabled world.<br>
We cruise around and it gets sent to a fixed location device nearby a<br>
busy street. Every hour or two a mobile phone passes by on its way to<br>
the airport. That mobile phone is going to get on a plane and go<br>
somewhere in the world.  We know this because of the location<br>
probability distribution. We know that device within hours is very<br>
likely to be in contact with a dedicated wired Internet connection. We<br>
dump every message we possibly can on him, starting with the messages it<br>
is mostly likely to be able to deliver followed by less likely messages<br>
because our connection is just temporary and will get dropped as we move<br>
out of range, possibly while we are still transmitting.<br>
That device lands at the airport in Europe somewhere where it disburses<br>
its messages to other mobile FP speaking devices. In fact, it probably<br>
already did so on the plane before everyone turned their phones off or<br>
even in the departure area while everyone was waiting to board. But it<br>
might also do so in the arrivals hall although it may not because it is<br>
satisfied that it has already delivered to enough other devices with a<br>
high probability of being in contact with a wired connection soon.<br>
In a nearby concesssion along the terminal on the way to the baggage<br>
carousel someone has discretely stashed a fixed FP speaking device. It<br>
spends all day receiving and transmitting messages to different parts of<br>
the world as the FP speaking mobile phones walk by on the way to their<br>
international flights. Via the probability broadcasts it knows who is<br>
likely returning to China, to Pakistan, to Venezuela, etc. although it<br>
only knows these places at lats/longs. There is also a similar box in a<br>
neighborhood on the main thoroughfare passing almost as many messages<br>
from the taxis and buses as they go by. Not to mention all of the FP<br>
speaking devices being carried by passengers furiously exchanging<br>
messages as they move throughout the airport.<br>
Our message eventually hits one of these devices with a wired or<br>
otherwise unmetered Internet connection where it hits a gateway which<br>
converts the message to a tweet, an email, a facebook entry, whatever.<br>
So how do we get return messages or even ACK packets (receipt<br>
verifications) back? Are ACKs even necessary? Probably not. Certainly<br>
not at the low level. Let the receiver reply to the message in their<br>
higher level protocol if they want to ACK it. This is like UDP.<br>
Say our contact (be it a person, a website, a twitter account, whatever)<br>
in the Free World receives our message, does whatever needs to be done<br>
with it, and wants to send us a message such as &quot;The Good Guys are<br>
sending in the cavalry on Monday, sit tight.&quot; Or someone could<br>
theoretically subscribe to a twitter feed via a gateway and have all<br>
tweets with a certain hash tag packaged up and sent to them.<br>
Their return address would have to be an approximate lat/long where they<br>
expect to be able to pick up the message. They may even choose a very<br>
specific lat/long which is nearby where they expect to be able to pick<br>
up the message but of course never their exact location, just something<br>
to report as their exact location when picking up messages to ensure the<br>
message ends up on a nearby FP speaking device and is directly routed to<br>
them first when they pass by to ensure they get their message.<br>
The message would be routed in the direction of their return address<br>
wherever possible. The message will either have some sort of To: address<br>
in the application layer (like email) or it will be encrypted<br>
specifically to them if they care about privacy. The receiving device<br>
would receive all of the messages the sender thinks it should have and<br>
then pick through them for specific messages addressed to them either by<br>
name or lat/long or whatever.<br>
Would the message from the Free World with Internet access ever arrive?<br>
Getting to a place with a wired net connection is a lot easier than<br>
getting from such a place to a specific area or town such that one might<br>
have a chance to pick up the message. What is the range of the typical<br>
wifi? Indoors or with various sorts of obstructions let&#39;s say 35m. A<br>
typical freeway has a lane width of 4m. So anyone within 8 traffic lanes<br>
(a whole freeway width, in the US) is within range. That actually<br>
creates a LOT of opportunities for message passing.  What are the<br>
chances that a device will pass another FP capable device on the<br>
freeway, find each other, and exchange messages? My wifi enabled mobile<br>
phone sees many wifi access points as I go down the road. How many<br>
people do you come within 35m of throughout the typical day? I bet it is<br>
a lot. Especially if you live in a densely populated area or travel on a<br>
freeway. The chances of coming into contact with another FP enabled<br>
device depends on how many you can get out there into the world but I<br>
don&#39;t think you would need nearly as many as there are mobile phones out<br>
there to do some real good.<br>
If a device has 4G of flash available and we set the average message<br>
size even at 10k we can store a LOT of messages. Do the math. We could<br>
store messages for such a long time that their chances of being<br>
delivered eventually actually get pretty high. The speed of delivery<br>
then becomes a function of how many FP enabled devices are out there.<br>
Why would anyone who isn&#39;t a revolutionary run this on their phone or in<br>
a fixed place device?<br>
You need a killer app to get everyone using it. That would also serve to<br>
obscure any dangerous revolutionary traffic. You need some chaff to hide<br>
Something like this could replace SMS messaging. Especially in a<br>
confined area such as a school, an office, or a small town or congested<br>
city area where the messages would potentially travel very quickly.<br>
Teenagers love this sort of thing.  Create an app to run on their smart<br>
phone. Sell very cheaply FP enabled SMS only devices. Let them spread<br>
all over the world.  Each device generates its own key, devices can be<br>
paired like bluetooth so you know who is who and won&#39;t suffer man in the<br>
middle attacks where the devices transparently encrypt the messages to<br>
each other&#39;s keys. Call it &quot;friending&quot;. Hide all the complicated fancy<br>
crypto stuff which would just scare people off, just claim the<br>
communications to be &quot;secure&quot;. Definitely avoid any certificate<br>
authority type nonsense. Use the ssh trust model. Anyone really betting<br>
their life on it would be obliged to understand the technology a little<br>
So it looks like software and mobile phone apps are the best way to go<br>
here. You could build a physical device and call it a freedom box if you<br>
really wanted but I would create it with the intention of it being used<br>
by kids as secure adult-proof communications devices for spreading<br>
high school gossip. Not a boring wall-wart which nobody will buy<br>
ensuring per unit costs remain high. But do make it small and with<br>
ability to connect to an AC power supply so it could function like a<br>
wall wart and possibly external antenna and be hidden somewhere. It<br>
wouldn&#39;t even need a graphical screen necessarily. Text only LCD<br>
displays very inexpensive compared to the fancy high rez touch sensitive<br>
smartphone displays currently shipping. Would kids go for pure text<br>
messaging ability and no voice, digital camera, web etc?  Who knows. But<br>
SMS sure is popular, especially in third world countries where this is<br>
likely to be needed. Most of SMS is just black and white text.<br>
Most of the world can&#39;t afford a fancy phone with voice anyway.<br>
Things to consider:<br>
Could a bad guy build a device or abuse the protocol to suck up all of<br>
our messages becoming a black hole preventing message delivery?<br>
How can we make such broadcasts inconspicuous yet recognizeable? How<br>
often should they announce so as to conserve power? Maybe only announce<br>
while moving. Perhaps as detected by accelerometer if we aren&#39;t fancy<br>
enough to have a GPS. Maybe announce whenever we passively listen and<br>
hear another device. If he just came into range he was moving so he was<br>
announcing. Some such discovery protocol needs to be worked out.<br>
It would be nice if we could somehow track replies vs who we sent the<br>
original message through. That way we could calculate the probability<br>
that any one particular node consistently fails to deliver. On the other<br>
hand, you can&#39;t have negative reputation on the Internet. You can just<br>
fake up a new identity. Perhaps even completely unnecessary if we can<br>
run into enough honest devices to get the message through. Maybe it<br>
would be better to track who likely got us a reply faster. That is a<br>
form of positive reputation which is more doable.<br>
Just my 2 cents. :)<br>
<font color="#888888"><br>
Tracy Reed<br>
<a href="http://tracyreed.org" target="_blank">http://tracyreed.org</a><br>
Freedombox-discuss mailing list<br>
<a href="mailto:Freedombox-discuss@lists.alioth.debian.org">Freedombox-discuss@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss" target="_blank">http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss</a><br>