On Tue, Jun 25, 2013 at 6:09 PM, Matthew Toseland <[email protected] > wrote:
> These discussions should really occur in public, especially as nextgens is > your mentor, not me! :) So I've CC'ed devl. > > I just realized I replied only to you! How did gmail do that?.. I'll be careful in future. On Sunday 16 Jun 2013 18:53:26 Nitesh Bharadwaj wrote: > > On Sun, Jun 9, 2013 at 12:51 AM, Matthew Toseland < > [email protected] > > > > > > > > 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. > > > > > Yes. I have changed the code structure with fred-staging as submodule. I > > have a question. By common source code do you mean - > > a) We have abc.java and abc_android.java for the files that are needed to > > be changed. And the ant script chooses the files depending on platform. > > b) abc.java contains code of all platforms. This is turning to be > difficult > > as we don't have compile time conditionals in java. #ifdef #ifndef etc. > > c) If you mean point a) then that is same as having different source > codes > > at different locations?? > > I'd probably go for (a), yes. How much of the code actually needs a > different version for Android? I mean, Android includes 99% of the Java 6 > API, apart from the GUI stuff. Only one or two files use GUI stuff, so it > should be possible to exclude that (it's only used by web pushing anyway)? > If db4o were to be replaced by db4o embedded, some portion of code might vary depending on the availability of functions. Apart from that most would remain unchanged > > > > > > 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. > > > > > Ok. > > > > > > > > > > 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! > > > > > I will be focusing on making the required changes to fred on Add a Friend > > page and work on the connection between mobile node and fixed node this > > week. > > > > I think providing multiple options would be beneficial so that users can > > choose depending on hardware > > > > Option1: > > > > A Wi-Fi direct (softAP on mobile node - stays active only until the > noderef > > is transferred to save battery) to legacy Wi-Fi connection (on fixed > node - > > assuming fixed node doesn't support Wi-Fi Direct although Windows 8 > devices > > now support) > > 1) A way to transfer the WPS pass key auto generated by mobile node to > > fixed node. > > a) Typing in the passkey on fixed node > > b) QR (assuming fixed node has webcam) > > Do it the other way around. Generate a QR on the fixed node and take a > picture with the phone. > Ok. The user types in the pass key only for the first time during connection establishing.. > > > 2) I observed that one mobile node always generates the same pass key for > > its softAP (Wi-Fi Direct) > > a) Advantage: Transfer the pass key only once per mobile node it is > synced > > up with and remember for all future noderef sync ups. > > b) Disadvantage: Security?? Some handshake to make sure that we are > > communicating with right node or some crypto?? > > Hmmm, is that intended? You should talk to nextgens. > > > > Option2: > > > > A bluetooth connection between mobile node and fixed node to sync up node > > references > > Some home nodes won't have BT. > User would select one of the option depending on the hardware available to him > > > > Option3: > > > > Only QR - Using the plugin implemented by Operheim to generate QR on > fixed > > node > > In which case you're just downloading the noderef as a QR? You would still > need to be able to verify it. Anyway you'll need to be able to transfer > data back to the node to finish setting up connections. So IMHO you need a > wifi or BT link, no? > This option is for home nodes with zero RF hardware (Wi-Fi and BT) and also not connected to router which also acts as AP. The initial noderef transfer would take place when phone scans the QR. The later on sync ups would happen when the mobile is connected to home node via a USB? A more organised description about the possibilities that may arise: 1) A node might be connected via Ethernet connection to a Wi-Fi router. We directly connect the mobile also to the router. Here encryption is necessary as other nodes might be connected to the same router. 2) The above node itself has WiFi connectivity. a) We still connect to the Wi-Fi router and reuse the code for #1 b) (Probable) We establish P2p between mobile and home node by Wi-Fi Direct (softAP) and Legacy Wi-Fi connection while the node still maintains internet connectivity through Ethernet 3) A node is without Wi-Fi hardware and is directly connected to LAN via ethernet a) So here, initial transfer would occur through QR. Later on, sync ups occur whenever the mobile is connected via a USB i) USB and Ethernet bridge and reuse code of #1 ii) Plain USB data transfer through java code b) If it has bluetooth hardware, use bluetooth based transfers 4) A node connected to LAN (say company LAN/ college LAN) and "has" Wi-Fi hardware which is not being used We use p2p WPA2 Wi-Fi Direct to WiFi here between softAP on mobile and home node 5) For users who want to use bluetooth for transfers , bluetooth option. IN BAND: #1, #2a,#3ai. These methods are in band and definitely need encryption from our side OUT OF BAND: #2b, #3aii, #3b, #4, #5. They may not need further encryption as we are using p2p only In each of the case 1,2,3,4 I'll have to choose one method for data transfer. Advantage of IN BAND primarily is reusability of code and heavy encryption Advantage of OUT OF BAND is that they are out of band methods! Note that one IN BAND(#1) and two OUT OF BAND(#4,#5) are compulsory for satisfying all cases. So, I'll have a choice only in case of #2, #3? Disadvantage of WiFi-Direct to Wi-FI connections (p2p) (#4,#2b) is that Wi-Fi connection on the home node cannot be assumed to be connected with mobile node (softAP) and we will have to either a) Request the user to establish connection either through desktop stock application b) Provide some way to establish connection through our application.The problem being there is no JAVA library on home nodes which does this work. We should either call runtime.exec() or use jni wrappers particular to each OS(windows, linux, MAC) selected automatically based on System...//getOSname Note that AFAIK this is not the case with either bluetooth(#5,#3b) or WiFI/WiFi-Direct in android which provide concrete java classes to achieve connectivity. So later on during the project, two mobiles can be connected using plain java without a hitch Thoughts in this aspect?
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
