18:59:28 <sysrqb> #startmeeting TorVPN Core Android Components 1 March 2022
18:59:28 <MeetBot> Meeting started Tue Mar  1 18:59:28 2022 UTC.  The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:28 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:59:51 <sysrqb> Hello! o/ anyone here?
18:59:58 <PieroV> o/
19:00:12 <sysrqb> Pad: https://pad.riseup.net/p/sponsor101-android-components
19:00:48 <sysrqb> Please add any additional agenda items
19:01:38 <aguestuser> o/
19:03:52 <sysrqb> Let's start, and others can catch up
19:04:22 <sysrqb> The goal of today's meeting is evaluating the core components used in Orbot
19:04:55 <sysrqb> as I said at the end of last meeting:
19:05:00 <sysrqb> > next meeting I'd like to discuss each component that orbot is using currently
19:05:06 <sysrqb> > and identity whether we need it in an arti-world
19:05:12 <sysrqb> > in theory, Orbot and TorVPN should have almost identitical internals
19:05:20 <sysrqb> > and I'd like to begin discussing what those internals are
19:05:28 <sysrqb> > and, along with that, whether any components can be shared with other platforms
19:05:42 <sysrqb> > i don't know if any of the current components should be used/reused
19:06:02 <sysrqb> I don't see any other agenda items
19:06:25 <aguestuser> none from here!
19:06:40 <PieroV> I don't have either
19:06:42 <sysrqb> does anyone have any thoughts on this topic, before I begin going through the list of components?
19:07:00 <aguestuser> noep
19:07:15 <PieroV> go ahead :)
19:07:21 <sysrqb> alright
19:07:45 <sysrqb> I listed the components on the pad - copied from the google doc
19:08:30 <sysrqb> the "Orbot Controller UI" is likely the primary component that will remain different between the TorVPN and Orbot
19:09:01 <sysrqb> orbot will have more experiemental UI/UX, and that will be under Guardian Project
19:09:04 <sysrqb> 's control
19:09:37 <sysrqb> OrbotService is interesting because Tor Browser is using a fork of this project
19:10:29 <sysrqb> My experience with the fork leads me to believe we should abandon it and support/develop OrbotService instead
19:10:56 <aguestuser> sounds reasonable!
19:10:59 <sysrqb> the fork we're using has this design: https://github.com/sisbell/tor-android-service/wiki/Architecture
19:11:28 <sysrqb> it is signficantly more complicated than OrbotService because OrbotService is more self-contained
19:12:55 <sysrqb> I'm under the impression that Guardian Project are willing to let "us" (applications team) take over responsibility for OrbotService
19:12:57 <aguestuser> would adopting OrbotService mean elminating the dependency on the "Tor Onion Proxy Library" .aar?
19:13:07 <sysrqb> but we need to verify that and have a conversation with them
19:13:14 <sysrqb> aguestuser: yes, that's correct
19:14:03 <aguestuser> cool. :) (keep going! :))
19:15:12 <sysrqb> I believe we need something like OrbotService in the arti-future
19:16:04 <sysrqb> so the real question is about how we adapt OrbotService for arti
19:16:27 <sysrqb> OrbotService *is* the interface between "tor" and the app
19:16:46 <sysrqb> sound reasonable?
19:16:55 <sysrqb> *does that sound reasonable?
19:17:10 <aguestuser> yup
19:17:20 <sysrqb> great
19:17:26 <PieroV> Do you mean it provides an API on top of the control protocol?
19:18:03 <sysrqb> yes
19:19:02 <sysrqb> it provides the Android/Java API used by the app
19:19:17 <PieroV> okay, however I'm not sure we have decided something about how the app communication should happen
19:19:42 <PieroV> but I don't remember in which meeting we talked about this topic
19:19:49 <PieroV> but as a first approximation, it makes sense
19:20:11 <PieroV> because we can say we keep the same API/update the existing service for the new communication thing
19:20:21 <sysrqb> there was a separate discussion in https://pad.riseup.net/p/ARTI_Interfaces-keep
19:20:26 <sysrqb> related to this topic
19:21:05 <sysrqb> but OrbotService may simply become the Android wrapper interface that is needed for apps
19:22:18 <sysrqb> i see OrbotService as being the single go-to library for integrating tor
19:22:28 <PieroV> yes, that makes sense
19:22:33 <sysrqb> and that seems useful with arti, as well
19:24:07 <sysrqb> The next component is Tor-Android
19:24:14 <sysrqb> https://github.com/guardianproject/tor-android
19:24:48 <sysrqb> i'm not certain we need this component in the future with arti
19:25:10 <sysrqb> but it could be adapted for arti, instead of c-tor
19:25:38 <aguestuser> if OrbotService communicates with arti, what would the purpose of Tor-Android become?
19:26:03 <aguestuser> or would it only remain relevant in a scenario in which OrbotService did *not* communicate w/ arti?
19:28:03 <sysrqb> that's a good question
19:28:29 <sysrqb> the situation is a little complicated because Tor-Android provides part of the Java API for communicating with tor
19:28:34 <sysrqb> https://github.com/guardianproject/tor-android/blob/master/tor-android-binary/src/main/java/org/torproject/jni/TorService.java
19:29:14 <sysrqb> (communicating/controlling)
19:29:18 <aguestuser> ^-- i recognize that class!
19:30:04 <sysrqb> as we go through this process we should consider merging Tor-Android's functionality with OrbotService
19:30:33 <sysrqb> there may be an argument for keeping them separate
19:31:10 <aguestuser> okay. so that seems like a useful "open question" to flag?
19:31:18 <sysrqb> yes
19:31:23 <sysrqb> (i'm taking notes on the pad)
19:31:25 <aguestuser> like we'd prefer to migrate the full Java API for talking to Tor (via arti) into OrbotService
19:31:37 <aguestuser> but we'd like to perk up our eyes for reasons not to
19:31:42 <aguestuser> as we explore the code bases more
19:32:21 <aguestuser> what might "good reasons not to merge into OrbotService" look like?
19:33:00 <sysrqb> some apps only want to inegrate arti without OrbotService's additional bloat?
19:33:05 <sysrqb> *integrate
19:33:32 <sysrqb> in, more simply, an app only wants to integrate arti with a minimal controller API
19:33:32 <PieroV> but then why would they reimplement only part of the wheel?
19:34:19 <sysrqb> i don't know, but these things happen
19:34:31 <sysrqb> we could say we don't support that
19:34:54 <aguestuser> or... there is some unforseen architectural reason why it is not simple to move the subset of functionality from Tor-Android into OrbotService (unforseen coupling/cohesion issues... something like that?)
19:35:00 <sysrqb> but we should understand if there are existing reasons for it
19:35:21 <aguestuser> yes, that seems wise! why did GP have these as 2 separate packages in the first place?
19:36:10 <sysrqb> i believe ther isn't a good reason now, but I'm not certain
19:36:21 <aguestuser> fortunately we know them! ;)
19:36:49 <sysrqb> indeed
19:37:01 <aguestuser> (i hear they make gr8 coffee? ;))
19:37:12 <sysrqb> and gifts
19:37:17 <aguestuser> :)
19:37:17 <sysrqb> anyway.
19:37:25 <aguestuser> </digression>
19:37:49 <sysrqb> Tun2Socks/Leaf. the network team's experimenting with a different/better solution
19:38:04 <aguestuser> oh last thing on Tor-Android -- might be worth some hunt for "first things we'd liek to move"?
19:38:29 <aguestuser> working through an example class or two (even as a thought experiment) might help us estimate scope of moving whole thing?
19:39:08 <sysrqb> hm. yes, we could do that
19:39:21 <aguestuser> (you might not need to. i might find it helpful.)
19:39:31 <aguestuser> (as a terrain-learning exercise.)
19:39:35 <sysrqb> there are three main components. 1) embed tor, 2) configure tor, 3) control tor
19:39:44 <aguestuser> but one reason not to move it might be "too much work!"
19:39:55 <sysrqb> we need experience with (1) for arti
19:40:01 <aguestuser> if we poked at a few classes, we could validate the assumption "not too much work" without doing all the work yet
19:40:15 <sysrqb> and (2) and (3) are works in progress in terms of defining that interface
19:40:35 <aguestuser> so the "thought experiment" would be highly conjectural?
19:40:42 <aguestuser> thinking about lots of things that don't exist yet?
19:41:06 <sysrqb> yeah
19:41:15 <sysrqb> at this moment
19:41:31 <aguestuser> could we produce useful requirements for people working on (2) and (3) by thinking about what we need to migrate?
19:41:32 <sysrqb> we should begin understanding how to accomplish (1)
19:41:40 <aguestuser> +1
19:41:45 <sysrqb> and i believe LEAP may be looking at that, already
19:41:57 <aguestuser> by "that" you mean 1?
19:42:00 <aguestuser> (1)?
19:42:17 <sysrqb> for (2) and (3), yes, we should be in the meetings where that is being discussed :)
19:42:32 <aguestuser> and by "looking at that" you mean the onionmasq project cyberta and ahf are working on?
19:42:34 <sysrqb> (1) is building and embedding arti in a library
19:42:42 <sysrqb> yes
19:42:49 <aguestuser> kk
19:43:05 <sysrqb> plus some other additional testing apps they're working on
19:44:04 <sysrqb> good?
19:44:14 <aguestuser> yup. just trying to capture that in pad
19:44:29 <sysrqb> i see, okay
19:46:33 <sysrqb> I believe we can consider Tun2Socks/Leaf as obsolete
19:46:50 <sysrqb> and arti will provide most of that capability
19:47:24 <sysrqb> Next: NetCipher
19:48:05 <sysrqb> This is an interestinf component because it relates to how multiple apps may control (start/stop) tor
19:49:13 <sysrqb> when TorVPN/Orbot is installed, we may want to give tor-aware apps an ability to communicate/interact/control tor
19:50:08 <sysrqb> we should investigate which functionality should be available and whether that should be a separate component
19:51:45 <sysrqb> does that sound reasonable?
19:53:46 <aguestuser> yes
19:54:11 <sysrqb> okay, let's stop here and pick up at the next meeting
19:54:13 <aguestuser> noting that the netcipher lib also does lots of network hardening
19:54:22 * sysrqb has another meeting in ~5 minutes
19:54:33 <aguestuser> cool1
19:54:37 <PieroV> okay, thanks!
19:54:39 <sysrqb> yep
19:54:44 <PieroV> o/
19:54:48 <aguestuser> o/
19:54:49 <sysrqb> okay, thanks PieroV aguestuser !
19:54:57 <sysrqb> have a good night
19:54:58 <sysrqb> o/
19:55:03 <sysrqb> #endmeeting