-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Michael Rogers wrote: > Hi str4d, > > Sorry it's taken me so long to respond to this. Having I2P > available as a library is really exciting. I'd like to experiment > with writing an I2P transport plugin for Briar, and I'd appreciate > your advice on the best way to do it.
I'm happy to help :) > > * We'd like to share code between the Android and J2SE versions of > Briar where possible. > > Do you think the Android library would be a good fit for these > constraints, or would we be better off using the standard Java > APIs? Using I2P as a transport, your best option is to use the standard Java APIs for streaming or datagrams. This gives your app full control over the tunnels and their keys, and the most transparency for pushing data over the network. The Android client library bundles the standard Java APIs - i2p.jar, mstreaming.jar and streaming.jar. Using it is equivalent to bundling those JARs in your application. So the main transport plugin code (managing tunnels and pushing data) _should_ be identical for both the Android and J2SE versions. The differences will only be in the code that manages the connection to the I2P router. Regarding this, the client library additionally provides Android-specific tweaks to help apps use the I2P Android app as their router. Some examples: - - i2p.jar is modified to enable communication with I2P Android over Android LocalSockets, which bypasses the TCP stack. - - An AIDL interface is bundled that allows apps to listen for status updates. - - UI helpers are provided to help apps prompt users to install and/or start I2P Android (like in NetCipher). By providing all this in an AAR, app devs can easily keep all components up-to-date. Even if you didn't use any of the additional features, it enables you to keep your I2P JARs current and working with I2P Android. Now, regarding the other constraints: > > * Briar and its transport plugins must ship as a single APK. If this constraint means that you can't require other APKs to be installed, then obviously you will need to ship your own router. But if your use-case supports having dependencies on other APKs (e.g. Orbot), then the Android client library will be sufficient. > > * Briar must be able to enable/disable plugins when moving between > wifi and mobile data, according to the user's preferences. I think > this might imply that we need to run our own separate I2P router, > as enabling/disabling a shared router would affect other apps. Network profiles could be implemented in I2P Android, so users can specify when I2P Android should start and stop the router based on their network connection type. This is something I plan to add to I2P Android anyway, and fits with how IMHO the router should be set up: all apps using I2P should use the same router, because: a) only one router is running on a device, b) user settings related to the router (not the client) are not duplicated between each I2P-enabled app, and c) I can't remember what the third point was going to be. But let's take a step back and look at the broader use case. As I see it, there are two situations that need to be handled: - - The user wants I2P to be enabled/disabled for _all I2P-enabled apps_. In this case, the best method is to have network profiles in I2P Android (as above), and apps listen for router status changes and act accordingly (which they can already do). - -> The Android client library could have an additional UI helper that apps can use to quickly direct the user to the I2P Android settings when they want to change the global profile. - - The user wants I2P to be enabled/disabled for _this app only_. In this case, the app can just shut down its I2P tunnels (which it has full control over) and disconnect from the router without needing to care about it. The router is then left running for other apps, while this app can have its plugin be enabled/disabled at will. - -> Perhaps an additional configuration option could be added to I2P Android, so that if it was started by an external application then it will automatically shut down when all external applications have disconnected. If your app still needs the flexibility of running its own I2P router, you can certainly do so. There are some factors you will need to consider; we have some guidelines for bundling I2P[0]. str4d [0] http://zzz.i2p/topics/1654 > > > Cheers, Michael > -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUP4aBAAoJEIA97kkaNHPnY3MP/2jAU3k/vLUl/W2rP6FIhshi Za49tmDaO/7WEtQHZLYWr5yIpSwjpSsigcdv13WM7DNmJrf5ygsZlWaO24doe0Bf XRMnaFSWZs4KoRkgQShv2zOSwxUPCQ/D6CV+3OdvcOlY8GOwnTSr7R94cmp7o+8T P8nbveTWgC+BiA4kR1xNNWT9mZALXSqZuWdpxer0U7IUx0sFulUEuzv0lZt8hhbt G7MRi2o1Su0ak0COklz7DGJZI3PBZ+/jMHctTHa5Rp+yvdOv6k4ApRoocz0JYSMA tbttqEBovBEg9d6B+nktWEqX6aTo0gQU9icdodADVRpCnMblb7UV/MGPlQoWStAB 8rv4RZqoCb/zJPj5UHM4lgjiXC/u2EQ/peVPRBCGbTl92Si5F4Zng1KJ5zDYEoL2 L0o26L9VsbJj1Dx9Ahnr+NIY3lCDIW6+ZYq2i3Tcn7u46ib63a/dCEG1m3uvHxsC 1EAA/DwateEZ+Cdtma6xN92j+0/D083uxHXscKYsbBAhZW+Gx8RmRZS6M3dm/q42 nQzPslSfwJanf7qdzSSyD30E0Z9b34etI+6fBixJlfkmDPgSgsCICIm6YHC0iKmv VmRee8VhLCIhSJkGhPPz1z69lBQZqinb1ZHSYSIKTSlC/YhNCi+JMcgSsN1hXQxy HnaFUoT8G9QrCl+oiiT2 =DfW1 -----END PGP SIGNATURE----- _______________________________________________ Guardian-dev mailing list Post: [email protected] List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: [email protected] Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/archive%40mail-archive.com You are subscribed as: [email protected]
