On Saturday 08 Jun 2013 17:37:11 Nitesh Bharadwaj wrote:
> First of all, thanks Freenet for giving me this GSOC opportunity.
> 
> Objective 1 (High Priority):
> 
> To provide android support to securely establish darknet connections, in a
> user friendly way, using various options like QR, Wi-Fi Direct etc. i.e we
> have android mobile nodes related to parent node. When two such mobile
> nodes agree upon, a darknet connection is established between parents
> 
>    - A method to exchange node references between two android mobiles, both
>    running light-weight freenet apps.
>    - A method to connect the mobile node to its parent and sync the darknet
>    peers
> 
> 
> Objective 2:
> 
> To attempt an initial port of fred to android
> 
> Though these two objectives seem distinct at first glance, they relate in
> the long run. For example, to provide sneakernet support utilizing the high
> bandwidth of Wi-Fi direct. Refer:
> https://emu.freenetproject.org/pipermail/devl/2013-March/036887.html
> 
> 
> Update :
> 
> I have started dealing with easy things for an android port first. One
> realization was java awt package (images etc.) is not available in android.
> So, I had to replace all the usages of java awt with their android
> equivalents (android.graphics package). This is also helpful in objective
> #1 to handle QR images on android.

Note that fred itself barely uses awt at all (iirc there is one toadlet that 
does but it's only used by web-pushing, which is of by default). The QR code 
however does use it.
> 
> Also, I have tested the LZMA compression library and the related fred code
> on android. It seems to work perfectly i.e. compress and read back cycle
> using both oldLZMACompressor.java and newLZMACompressor.java.

Glad you fixed that. Was that a problem with your testing framework, or does it 
need some actual fred changes?
> 
> The github link for android port under development and related testing is
> https://github.com/NiteshBharadwaj/Fred-Staging-Android

IMHO it would be best if we could have a common source code, and just have 
different scripts to build Freenet on different platforms. Whereas the above is 
definitely not forked from the main fred repository. Also it includes binaries 
in the repo, which is usually a bad thing.
> 
> With respect to QR, I have cloned Operheim's implementation of
> NoderefQRCode which is a plugin to freenet and can convert node references
> into QR code and decode them back.
> https://github.com/Thynix/NoderefQRCode
> 
> Since, this part is already implemented by Operheim, I have just run a few
> tests.
> I tried to scan the generated QR using popular applications available on
> google app store. It could decode correctly 7 out of 10 times while 3 times
> it decoded a random number!
> Using the original decoder (in NoderefQR), it gave similar results except
> that instead of random number it ran into check sum exception once or twice.
> 
> The basic problem I noticed is bigger the size of the string to be decoded,
> the longer it takes (quite irritating) and more the chances of a wrong
> decode.
> 
> During the planning stage, we thought about using QR codes only to
> establish Wi-Fi Direct connection between two mobiles. The actual node
> references are exchanged via Wi-Fi direct. This seems a better option
> compared to encoding whole nodereference in QR (We could provide multiple
> options anyway). The high band-width during such transfer can also be
> utilized for sneakernet support later on.

Yes, or you will have to do some work on shrinking noderefs first. Let me know 
if this is a serious option, we have lots of ideas about it, but really IMHO 
exchanging via wifi direct is probably best. That can use NFC or Bluetooth for 
short range key exchange, or you could use QR codes to exchange a password to 
be used for wifi encryption.
> 
> Specific Questions:
> 
> 1) (Related to darknet support) On the main freenet node, should I let this
> be an optional plugin or directly add options to fred-staging  to
> synchronize peers with its mobile node.

I'm not sure. Probably best to make it part of fred. Certainly it needs to be 
integrated closely, e.g. we may want something on the Add a Friend page.
> 
> 2) (Related to android port) db4o offers a package Db4OEmbedded and had
> several positive reviews online. So, is it still necessary to rip out db4o
> from fred?

db4o will be removed from fred soon. So don't worry about it one way or the 
other.
> 
> Suggestions and Comments are most welcome.
> 
> Thanks for reading through!
> 
> For more details related to project, please visit
> http://niteshgsoc2013.blogspot.in/
> 
Thanks!

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