15:12:59 <sysrqb> #startmeeting Tor VPN/Orbot components 23 March 2022
15:12:59 <MeetBot> Meeting started Wed Mar 23 15:12:59 2022 UTC.  The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:12:59 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:13:08 <sysrqb> hello and welcome!
15:13:41 <aguestuser> :)
15:13:41 <sysrqb> https://pad.riseup.net/p/sponsor101-android-components
15:13:53 <sysrqb> that is where we were previously taking notes
15:14:11 <n8fr8[m]> So, how can we help and/or where are the sticking points?
15:15:47 <n8fr8[m]> One piece of context, is that the funding support the VPN work, also is meant to support broadening developer adoption of tor as a component, and thus, decisions we are making here about when to fork/merge/cherry-pick/EOL things should take that into consideration
15:16:27 <sysrqb> yes, agreed
15:18:11 <sysrqb> two major points that need to be discussed are: 1) does orbot's internal architecture change (and, therefore, does Tor VPN's architecture) when we integrate arti?
15:18:55 <sysrqb> there is an argument for trying to "drop" arti into TorService and keep everything else roughly the same
15:19:00 <cyberta> moin
15:19:11 <cyberta> (hi)
15:19:41 <sysrqb> but, there is also an argument for taking advantage of this opporunity and making tor integation easier, and leveraging arti as a fresh(er) start
15:20:02 <sysrqb> i don't expect we'll come to an agreement in this meeting around this
15:20:17 <sysrqb> but is an on-going discussion we should have
15:20:46 * n8fr8[m] waiting for bim to type :)
15:21:09 <sysrqb> the second major point: 2) who/which team/org(s) should be maintaining which component - the gdoc indicates some thoughts in this direction, but we should come to agreements
15:21:34 <sysrqb> and, 3) can the architecture be simplied in any ways (possibly related to (1))
15:22:02 <bim[m]> I imagined arti would be deployed into something like tor-android, replacing that C tor binary with arti. Provided the minimal java wrapping around the binary in tor-android's TorService doesn't change, Orbot in theory wouldnt' need any significant changes
15:22:17 <n8fr8[m]> it might be best to use onionshare-android as primary consumer of current and future components, since it is the latest, best clean room impl of tor on android: https://github.com/onionshare/onionshare-android
15:23:02 <_hc[m]> I think we should frame discussion as more bottom up: lets design the core pieces to fit in the modern world (e.g. arti/rust, TorService/Android-native, etc).  Then adapt the old codebases to fit into those.
15:23:16 <n8fr8[m]> bim[m]: we should not that the current JNI wrapper for tor is just calling main() without any other functions exposed. i think that could change perhaps, so we don't have to rely on control port sockets, etc.
15:24:28 <sysrqb> yes, there are separate discussions (where we'd love your involvement/input) around designing a clean API for arti
15:24:42 <sysrqb> threeletteracronym[m] has been in some of those discussions, already
15:24:54 <_hc[m]> n8fr8[m]: onionshare-android does use TorService but they didn't go android-native and instead hacked their own direct access to the private UNIX domain socket.  That should not be emulated
15:25:14 <sysrqb> but, this is an opportunity to allow controlling/configuring "tor" in a reasonable way
15:25:53 <sysrqb> (see relevant meeting pad: https://pad.riseup.net/p/ARTI_Interfaces-keep)
15:26:20 <n8fr8[m]> one consideration is running in-process vs separate process as a service. with Orbot we run everything in process, but OnionShare runs in a separate process. I think both should be tested, supported, etc, since those are both acceptable models of how an Android Service works.
15:27:02 <n8fr8[m]> in the VPN use case, you have one VPNService instance, and ideally there isn't another service. I can see, for that case, that you would just pipe the TUN i/o streams directly into arti within the single VPNService, and be done with it.
15:27:16 <sysrqb> i feel like this could need its own dedicated meeting for working through these details
15:27:37 <n8fr8[m]> Yes, we don't have to get into arti design specifics now.
15:27:38 <sysrqb> i'd like this meeting to make sure everyone's on the same page, and then we can go into details leter
15:29:31 <n8fr8[m]> I think recognizing that there are a few different usage models by developers. I am seeing how a VPN app might want to just use arti directly once it has the UserSpace IP support, while most other apps, like OnionShare or Save, should use it in the TorService/tor-android model, as a proxy.
15:29:32 <cyberta> n8fr8[m]: I agree with your statement about the VPNService
15:30:02 <n8fr8[m]> Orbot on Android is a hybrid since it both offers a VPN service and a tor daemon/proxy for other apps to utilize.
15:30:31 <sysrqb> n8fr8[m]: our discussions have been around providing both "interfaces" in the vpn, too
15:31:12 <_hc[m]> it is important to also consider that Google has put a lot of effort into making WorkManager a reliable way to run short and long lived background tasks that tie into the system scheduling.  We really should be moving towards it as much as possible
15:31:29 <_hc[m]> plus it has good debugging tools
15:31:47 <cyberta> _hc[m]: I don't see that point
15:31:58 <n8fr8[m]> eighthave[m]: Agreed. the VPN API they provide has a different long-lived lifecycle model however.
15:31:59 <_hc[m]> so native Android `Services` are good, but WorkManager is better
15:32:42 <cyberta> +1 what n8fr8[m] says, VPNService can run long-lived
15:32:44 <_hc[m]> I know little about the VPN, so I cna't speak to that.  But for Tor/arti, PTs, or any other thing running in the background
15:32:57 <cyberta> (in background)
15:32:58 <_hc[m]> WorkManager is the way forward
15:33:00 <n8fr8[m]> cyberta: in the case of integrating Save for Android's upload-over-tor functionality, the WorkManager is a better approach that can bootstrap tor for a single operation, vs starting a Tor foreground service
15:33:40 <cyberta> in the VPN-Service model we would want to run the VPN all-time or?+#
15:33:46 <n8fr8[m]> long-live vs short-lived; service-oriented vs task-oriented... i think these two models are emerging as both valid ways to use tor that may require different considerations on the API/developer library front.
15:34:16 <sysrqb> +1
15:34:17 <cyberta> ok
15:35:11 <n8fr8[m]> or for example, we are building Radio Free Asia's mobile news apps... it needs to periodically sync new content. Rather than starting/stopping a Service instance with Tor for that, designing around the Workmanager model is the more modern approach.
15:36:03 <bim[m]> cyberta: worth noticing that  by default on Android 29+ users can configure VPNs to be running all the time https://developer.android.com/reference/android/net/VpnService#isAlwaysOn() (though this can be disabled)
15:36:11 <cyberta> In my understanding (until now) I thought the User would want to run tor most of the time for most of it's apps
15:36:35 <cyberta> bim[m]: I know :)
15:36:41 <n8fr8[m]> brb
15:36:43 <Ankit> AFAIK, WorkManager API are designed more towards on way flow, and the scheduling of task is not guaranteed to execute in timely manner.
15:37:08 <sysrqb> we're investigating both ways - always-on with per-app exceptions, and per-app tunneling
15:37:45 <_hc[m]> with TorService and WorkManager, we have more fleixibilty for how to deliver on the UX of having Tor always on.  For example, with quick start times, tor can be started on demand
15:37:47 <cyberta> both ways might work while the vpn app is always running
15:38:13 <cyberta> but I see that there are different ideas how the vpn service is used
15:38:15 <_hc[m]> but maybe that doesn't fit with the VPN API
15:39:47 <sysrqb> it sounds like we should have a separate meeting where we sketch the app-integration scenarios, and which architecture works best in each
15:40:33 <sysrqb> and then we work "backwards" and see how best we can integrate arti in these architectures
15:40:41 <cyberta> +1
15:40:51 <sysrqb> i liked thinking about this from the ground-up - starting at arti
15:41:25 <sysrqb> but this discussion makes it clear that we should think of this from an "android-native" design, and build around that
15:42:48 <sysrqb> i'd like to use the android-components meetings for this purpose
15:43:10 <sysrqb> but apparently the current timing is not very good for everyone who should be there
15:43:28 <sysrqb> so i'll create another poll and email it, so we can find a better time
15:44:42 <PieroV> the current time is becoming 21 in CEST soon
15:45:08 <sysrqb> this meeting has been productive in helping us re-focus on the important pieces of this project - and future app integration
15:45:21 <sysrqb> PieroV: indeed :)
15:45:30 <sysrqb> that seems a little late, as well
15:46:09 <sysrqb> i'll create a poll and we can find a regular meeting time where we can continue these discussions
15:46:22 <cyberta> thanks sysrqb
15:46:56 <aguestuser> +1
15:46:57 <sysrqb> any final thoughts/comments/questions for this meeting?
15:47:10 <sysrqb> i don't want to go passed 16UTC, due to other meetings
15:47:16 <sysrqb> so i'm happy ending here.
15:48:29 * sysrqb hears nothing
15:48:35 <aguestuser> sounds good!
15:48:39 <bim[m]> bye ~ im happy to elucidate any existing orbot architecture type things whenever
15:48:46 <sysrqb> thanks everyone! i'm looking forward to continuing these conversations!
15:48:55 <sysrqb> bim[m]: awesome, thank you!
15:48:57 <cyberta> oki, cu
15:48:57 <n8fr8[m]> One last though about future discussions
15:48:58 <_hc[m]> thanks!  I'd be happy to discuss further, and definitely ping me with questions!
15:49:04 <Ankit> bye :)
15:49:05 <sysrqb> n8fr8[m]: yes? :)
15:49:32 <n8fr8[m]> - i think talking about Tor VPN as VPN vs proxy-for-other-apps is something I'd like to dig into more, as it impacts our plans with serving developers
15:49:42 <n8fr8[m]> and also Leaf-vs-arti-userland
15:50:06 <n8fr8[m]> EOL
15:50:18 <sysrqb> sounds good
15:50:48 <sysrqb> we've had some other similar discussions, but this group should have that conversation and come to an understanding, as well
15:52:09 <sysrqb> alright, thanks everyone!
15:52:11 <sysrqb> #endmeeting