[guardian-dev] I2P Android client library (was Manage Orbot from external app: Tor admin?)

[str4d]

-----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-----