On Sunday 21 Apr 2013 17:35:57 Nitesh Bharadwaj wrote: > Hi Matthew Toseland, > > Thanks for reading through my post and for the valuable suggestions. > > 1) How is this different to Haggle? > Haggle seems to be a well-developed and organised project. My > original idea is quite similar to haggle except for the following > differences: > > a) This uses Wi-Fi-Direct. So, it makes it simple since I don't > have to go to the link layer > Unless absolutely necessary -> No root access required > b) The darknet approach as you have suggested in comparision to > opennet.
So it only exchanges data with known friends, and has some means to find and authenticate them when they are nearby. > c) It isn't opportunistic > > 2) How does/should it relate to Freenet? > On a broad level, it relates to Freenet by allowing the spread of > information to many peers thereby allowing a greater freedom of > information... i.e. it fights against information censorship enforced by > pricing internet connectivity exorbitantly. > > It is anonymous like freenet . I plan to use a Freenet kind of network where > each node offers some disk space for sharing. Nodes can request their > friends but their friends can route the requests through their friends(like > darknet with routing)... Meaning long term requests? This means substantial changes to Freenet... Obviously you can use Freenet's routing (locations etc). > > Transferring data between two phones or a set of pre-defined phones is > straight forward using existing Google wifidirect API's. > So what I originally intended to do was as follows: > > 1) Achieve data direct transfer between friends initially. > Adding darknet functionality > 2) Each node has a cache consisting of its own requests (i.e. requested > by user). > 3) Now, if two such nodes come close, they exchange their caches first > and check if they can handle any requests You mean check whether they already have the data that their peer wants? > Adding routing functionality > 4) Storing their friends' request cache when an exchange takes place. > Here, the node doesn't know which friend has requested. Now, this node > becomes intermediate/ > neutral node for the particular request. So you relay all the requests? Or the requests that are "appropriate" for this peer based on routing? Bearing in mind that at the time only one peer is available ... but you could forward to a different peer later, IF it becomes connected. I believe that's what's "opportunistic" about Haggle - it can both query nearby nodes to see if they have the data it wants, but also broadcast i.e. forward the same request to several peers. The catch is this doesn't scale. > 5) If the neutral gets the data, it stores the data for certain of > period time. If it meets a friend node requesting the particular data in > that period, then the request is acknowledged. > 6) Here, the requests are prioritized in the cache. i.e. friends' > requests have high priority, friends of friends' requests slightly lower > priority and so on. So, during cache exchange, the data corresponding to > requests with less priority get wiped off depending on the amount of > reserved space the neutral device has allocated. Won't the priorities give away which are local requests? Of course HTLs have the same effect on Freenet. > > Note: Here, friends are defined as that they know each other's IP or they > have recently established a Wi-Fi-Direct connection using a key based > security check or touch based security check. Also, group connectivity is > possible using Wi-Fi direct. So all people of such a group are all each > other's friends. IPs aren't static. You need to use a cryptographic identity. > > As it has already been pointed out, this has high latency like sneakernet. > Also, since each friend carries with him the requests of all his friends' > requests until requests expire, it introduces space constraint. > > 3) Are you planning to mostly use publish/subscribe? And routing? > 4) If you have routing, how do you assign "locations" for routing between > devices? > > I intended to use a handshake protocol where there is no direct addressing > to nodes... As soon as a request is made by the user, it is stored along > with a key 'K' and when connected to a different device, the other device > gets the 'K' during cache exchange. This request is then routed only using > that particular 'K' generated initially. All devices in this chain know only > their status (Requested/ neutral/ acknowledged) and know nothing about > others' status w.r.t 'K'. Accordingly, they handle data. The 'K' request > expires globally after certain period of time. I don't understand. K is the node's identifier? Or of the content you are trying to fetch? Or ...? > > So once any two nodes come close by, their allocated caches need to be > compared. I haven't given a good thought but I guess this would be fairly > anonymous. The only problem I see here is regarding data memory constraints. Right, mobile devices often have limited storage, but this is improving... > > Here bloom filter can be used if space constrains. > > 5) Is it feasible to make sufficient progress during the GSoC? > > Porting Freenet completely to android with all its functionalities and > adding Wi-Fi Direct capability and/or reducing the battery overhead is > definitely a time consuming process.. Instead I intend to focus on one of > the smaller sub parts... Then it's not Freenet. Why should I accept, or mentor, a project that has nothing to do with the Freenet software? Should we mentor projects that are vaguely related to Freenet? > > I intend to work on either of the following objectives: > > 1) Darknet as mentioned above > or > 2) Porting Tahrir to android and adding Wi-Fi Direct functionality. For > example, If nodeA without internet is following nodeJ (JLo) and she tweets. > It reaches nodeB with internet connectivity first and then to nodeA who is a > friend of nodeB when they come close. Right. Talk to Ian about this, but IIRC he already has 2 students... > Or > 3) The idea you have suggested to use "main" mobile nodes is really clever > and I would definitely like to work on it. But, it would mean I will have > to port Fred's code completely to android to ensure anonymity during > exchanges between main node and freenet. It is quite a challenging task. IMHO porting Freenet to android is trivial. 99% of Freenet's code uses APIs that are included in android. The main difficulty is the database code. And for the mobile version you could just not use it at all. > > I am still trying to organise my thoughts and would like to contact you in > case of any doubts... Thanks again for reading through my posts > > Sincerely, > Nitesh.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
