On Saturday 30 Mar 2013 12:21:51 Michael Grube wrote:
> You may want to consider that the traffic from freenet may significantly
> wear down any mobile device's battery. That being said, a "lightweight"
> android client might be amazing. You may also want to consider working to
> put Tahrir(http://github.com/sanity/tahrir) on Android, which may be easier
> on a mobile device's battery.
> 
> Just some thoughts. Go for it!!

Right, the main problems are:
- The amount of traffic freenet generates will get you a huge bill or get your 
data package blocked.
- Mobile networks are usually severely restricted anyway, e.g. blocking UDP.
- Battery life, as above.

However there are a number of things that might be interesting, possibly in 
collaboration with a fixed node:
- Exchanging friend connections. If you can just bring your phones close 
together to set up a friend/darknet connection between your "main" nodes, that 
would be very interesting. QR codes are another possibility.
- Remote access to your main node, without using centralised systems to look up 
its IP address, possibly maintaining connections to some of your friends' 
nodes, but with the main node doing most of the work.
- A lightweight node as Michael suggests, probably request only (no routing of 
incoming requests); darknet only, since it wouldn't work well on opennet.
- Sneakernet: Transfer large quantities of data (you have a big XD card 
installed, right?), via short-range high-bandwidth wireless (e.g. UWB, 802.11n 
etc), when you and your friends' phones are close together. Once you get home 
your phone downloads to your fixed node in the same manner. This is 
particularly useful for subscriptions of various kinds (which we don't yet 
support, but are planned), but also for long-term downloads (e.g. of big files, 
video files, rare files), and also opportunistically filling up empty 
datastores. The bandwidth is quite interesting too: Lets suppose you meet up 
for an average of 10 minutes to share a pint, 5 days a week, and make an 
average 200Mbps. That's enough time to exchange 14GB, which averages 130KB/sec 
over the week, which by Freenet standards is very respectable. And it's purely 
local communication; The Man never sees it. It can complement your regular node 
to node communications quite efficiently: they can determine what to transfer 
ahead of time, for example.

Obviously there may be other architectures that work better for sneakernet. One 
"opennet" way to do this is Haggle, which is the electronic equivalent of 
asking around on a train for whether somebody has a book you want. We're only 
interested in "darknet" approaches here. 

In principle sneakernet could be done purely on cellphone nodes - but bear in 
mind the limited storage, problematic networking if you want some real-time 
comms, and very high latency if requests have to be routed; routing would be a 
major challenge with *no* realtime comms, since we can't swap locations etc, 
and also long-term requests don't exist yet, though IMHO we could implement 
*some* functionality for sneakernet tomorrow (opportunistically filling 
datastores eg), and some more once we have bloom filter sharing. IMHO the best 
way forward long-term for freenet is pi-like home-server boxes combined with 
thin cell clients.

Anyway ... before we can do the advanced stuff, the easy stuff is likely to be 
useful.
> 
> On Sat, Mar 30, 2013 at 8:15 AM, Rodger Fox <[email protected]> wrote:
> 
> > Hello all.
> > I just just joined here. In fact I haven't even peeked at the source code
> > yet, so excuse me if I'm being rude or ignorant in anything I suggest here,
> > but has anyone here considered porting freenet to mobile devices.
> >
> > If it's of interest to others, I'd like to initiate the task, particularly
> > for android.
> > I'll stay brief until I get some feedback. Any thoughts on this?

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Devl mailing list
[email protected]
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to