On Saturday 20 Apr 2013 07:51:37 Nitesh Bharadwaj wrote:
> Respected Sir/Madam,
> 
> I am a sophomore from Indian Institute of Technology Delhi. I am quite
> interested in P2p and would like to work for the development of P2p. Since
> Wi-Fi Direct is relatively new, its potential is largely unexplored.. By
> using Wi-Fi Direct, we could have a local P2p sharing between android
> mobiles. Now a days, we are having smart TV  sets and smart cameras that
> have Wi-Fi-direct functionality. I feel this could be a revolutionary
> technology and would be available on latest and upcoming devices. 
> 
> For example, one can look and share files with anybody who is having an
> Android device and is close by. This way without using internet/data
> connectivity data can be shared. 
> 
>                 Sharing without internet connection    -->   Censorship
> impossible
> 
> Now data that is shared at local level could move to other people when these
> people visit different places.. Now using Bacon number kind of notation, it
> would take no more than 10 hops for the data to reach from me to you without
> internet/data connectivity!!!

This is certainly interesting. The big questions are:

1) How is this different to Haggle?
https://code.google.com/p/haggle/
Basically, Haggle opportunistically transfers data between phones; it's 
"opennet" in Freenet terminology, i.e. it will happily request a (possibly 
illegal) file from anyone who happens to be nearby.
2) How does/should it relate to Freenet?
It has long been planned that Freenet should have something like this: Support 
for transferring data between your phone and your friend's phone when they are 
close together. There are various other things we can do with a cellphone 
client, see the recent thread "[freenet-dev] Native android client?". This 
would be "darknet", i.e. we'll transfer data only between your phone and your 
friends' phones (possibly including friends of friends), not *anyone*'s phone. 
This is a variant of "sneakernet" support (true sneakernet being "high latency 
communications by passing arounds disks/CDs/USB keys).
3) Are you planning to mostly use publish/subscribe? And routing?
One problem with this is Freenet doesn't really support pub/sub at the moment. 
However as the Haggle folks point out, pub/sub works better for this sort of 
thing than routing does. IMHO we would need both. Publish/subscribe is good for 
receiving the latest blog post or tweet (or its freenet equivalent; Freenet has 
Sone which is somewhere between Facebook and Twitter, but anonymous). But to 
fetch a specific file that nobody near you has, you need routing. Which means 
you send out requests and they get relayed through your friends for 10 hops or 
so ... and the data comes back weeks later, since each hop may easily take a 
day. And that would mean some fairly big changes to Freenet to support 
long-term requests. Another option is you might be able to do something with 
opportunistically transferring data - either data that we specifically want 
(this is related closely to "Bloom filter sharing", an old proposal for freenet 
nodes to tell their peers what is in their datastores), or just data in general 
from their datastore to fill up our datastore.
4) If you have routing, how do you assign "locations" for routing between 
devices?
IMHO for now all mobile nodes should be the client of a "fixed" node. This 
eliminates the problem.
5) Is it feasible to make sufficient progress during the GSoC?
I doubt it ... but maybe you can figure out a sub-project that can be 
implemented in the time?
> 
> My Strengths:  
> 
> Android Development - Both Native and using SDK

We don't necessarily need full sneakernet support for an android app to be 
useful. For example, making it easy to exchange node references (i.e. add 
friends) via your mobile phone would be very useful. *PLEASE* read the last 
message on the thread "[freenet-dev] How to make a mobile Freenet work well was 
Re: Native android client?".
> 
> Programming and Data Structures - Developed small multiplayer games
> (connecto , tic tac toe etc)
> 
> Signal and Image Processing (If that could be of any use)
> 
> Sensors 
> 
> Please reply if you find this an interesting project for GSOC. Also, you
> could give suggestions to improve my idea.

It's interesting, but I have my doubts as to whether it is feasible. But please 
do apply!

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