-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 16/08/14 01:00, str4d wrote: > This seems like an excellent time to announce that I have pushed > the first release of the I2P Android client library to Maven > Central (net.i2p.android:client:0.1). For now, it simply bundles > our standard Java APIs along with some Android-specific code for > talking to the I2P Android app over our standard client API (I2CP), > and some AIDL interfaces for obtaining the status of the I2P > Android router. This allows app devs to create I2P sockets using > our streaming and datagram APIs, and have full control over their > tunnels. > > For some applications (like orWall), simply having the ability to > create tunnels in I2PTunnel (which provides some standard types, > like a SOCKS client proxy) would be sufficient. So the next stage > of development would be to create an Intent interface for > I2PTunnel, like is being discussed for Orbot. > > Since this mailing list is full of people designing privacy-aware > Android apps: what would you like to see in this client library? > What use cases do you envisage? Should I separate the AIDL > interface into a separate library, so you can query the router > status without needing to have the entire client-side API (if you > only wanted to use the Intents API)? Where should I put the pony?
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. Constraints: * Briar and its transport plugins must ship as a single APK. * 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. * 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? Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUNUBmAAoJEBEET9GfxSfMd2kH/iyWK9tpRyF8BDM3mMaFLDKb YxRkS9F6/ThVAzvvXnsVjM9iF0s+PCkqKAqrK/Fj2c7e5IWgOXm1pcMgI1dVxTJk LK9vnbZ9R60xMiOVgZY+/LgS6GERm0XqFXl2nirSBv1SyeqppotPf14xXy+/LJh8 Vmqwfa3VnSvzzSSQwDrX6jhj47dX6pygP9xaEJjxzbMBZfujDxjjzeTzRagH94Ut 8rTDEYcuIAZhenycycu/pxAVMDo0On9I+41Bt4ch3GgLfgeUJE/GcWi1w8z8GYqO fumjbxp70g9t54xQzNw8q8z2ybLBKEHBVK1nZ4nTVA/Z8SgzK6zzrm8HeYy1VJQ= =Oe5x -----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]
