17:01:31 <sysrqb> #startmeeting Core Android Components 6 April 2022
17:01:31 <MeetBot> Meeting started Wed Apr  6 17:01:31 2022 UTC.  The chair is sysrqb. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:31 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:02:01 <sysrqb> Pad: https://pad.riseup.net/p/sponsor101-android-components
17:02:10 * sysrqb wonders who else is here
17:02:43 <sysrqb> aguestuser: cyberta: _hc: n8fr8: .
17:03:21 <cyberta> moin
17:03:40 <cyberta> (hello)
17:03:41 <sysrqb> allo
17:04:29 <kwadronaut[m]> o/
17:05:01 <AnkitGusai[m]> Hello
17:07:39 <sysrqb> okay, let's get started
17:07:50 <sysrqb> i added some agenda items at the top of the pad
17:07:57 <sysrqb> please add more if you have any
17:08:08 <n8fr8h[m]> Here, but putting out a mini fire. Will participate as best as I can today.
17:08:23 <sysrqb> n8fr8h[m]: thanks, understood/no worries
17:08:40 <n8fr8h[m]> we should really get bim in this channel. threeletteracronym is :)
17:09:23 <sysrqb> yeah. i pinged them in the vpn channel
17:10:27 <sysrqb> we started organizing the work that we need to do in this group
17:10:53 <sysrqb> and we opened some issues and began labeling them
17:10:59 <sysrqb> https://gitlab.torproject.org/tpo/applications/vpn/-/boards
17:12:16 <cyberta> these tickets are still quite generic :)
17:12:27 <sysrqb> going forward, i want us to keep issues updated and open new tickets when we find new dependencies of an existing task
17:12:46 <sysrqb> cyberta: yep
17:13:14 <cyberta> do we use them to collect subtasks?
17:13:42 <sysrqb> yeah. i would like people taking responsibility for some of these issues and then create subtasks
17:14:21 <sysrqb> we (Tor) are still experimenting with how subtasks are documented in the meta issue
17:15:11 <sysrqb> two common solutions are adding related issues, or using task lists, like tor-browser-build#40446
17:16:13 <sysrqb> i don't have a strong opinion, except that the task lists provide more flexibility for adding comments in the meta ticket
17:16:40 <sysrqb> but you all can experiment and find which option works best for you
17:17:11 <cyberta> task lists just like the example you posted seem to be good for me
17:18:11 <sysrqb> okay, cool.
17:18:12 <cyberta> how do we realte these tickets to the ongoing onionmasq experiemtns
17:18:19 <cyberta> *relate*
17:19:17 <sysrqb> good question
17:19:19 * n8fr8h[m] adding notes to pad and tickets
17:19:35 <cyberta> currently we partly figure out how the VPN might interface with arti
17:19:45 <cyberta> in onionmasq
17:20:12 <cyberta> maybe we can cross-link these tasks in https://gitlab.torproject.org/tpo/applications/vpn/-/issues/5
17:20:21 <cyberta> for example
17:20:41 <sysrqb> cyberta: yes, that seems good
17:21:13 <PieroV> I think that we may have some problems with permissions
17:21:15 <sysrqb> at a global scope, we have Boards that cover the entire Tor org for this project
17:21:20 <sysrqb> https://gitlab.torproject.org/groups/tpo/-/boards?milestone_title=Sponsor%20101%20-%20Tor%20VPN%20Client%20for%20Android
17:21:42 <PieroV> IIRC I (as an app team member) I cannot link our issues in all teams/namespaces/whatever is called
17:22:03 <sysrqb> PieroV: that's possible, but we can ask ahf and dgoulet for help when that's needed
17:22:18 <sysrqb> it's annoying, but...
17:23:03 <PieroV> right, we can do it this way
17:23:42 <PieroV> I'm not sure everybody can add the milestone either, but we can solve in a similar way
17:24:02 <PieroV> (and it makes sense that the PM sets it)
17:24:10 <sysrqb> yeah
17:24:12 <cyberta> shouldn't we get the permissions to work independently?
17:24:29 <cyberta> so that we don't block ourselves
17:25:12 <sysrqb> cyberta: ideally yes, but sufficient permissions within a project means you get access to more info like confidential issues
17:25:20 <sysrqb> that should be fine for onionmasq
17:25:39 <sysrqb> so i don't see a reason why ahf/dgoulet wouldn't give you permission in that repo
17:25:51 <cyberta> right
17:25:55 <sysrqb> but it becomes more complicated for arti and such
17:26:33 <cyberta> what about https://gitlab.torproject.org/tpo/applications/vpn/ ?
17:26:46 <cyberta> it seems to be more like a meta-repo right now?
17:27:44 <cyberta> that would be then sufficient to cross-reference, if we get all permissions needed in these both repos
17:28:34 <sysrqb> yes. in the future I expect it will hold the code repo for the torvpn, but you'll probably have full permission for that anyway
17:28:58 <sysrqb> so, yes, i believe you're correct
17:29:31 <cyberta> ok, great :)
17:31:47 <sysrqb> n8fr8h[m]: thanks for your comments
17:32:53 <cyberta> other than that,  LEAP can add some tasks we expect in both meta-tickets
17:33:17 <sysrqb> cyberta: thanks, yes, please do
17:33:30 <cyberta> as a starting point
17:34:34 <sysrqb> n8fr8h[m]: I'm interested in finding 1) an arrangement/agreement with GP and Tor around OrbotService/TorService and (co)maintainership, and (2) find a reasonable "fork point" where Orbot and TorVPN diverge, but both projects share a common core
17:34:59 <sysrqb> ultimately, I dislike the idea of Tor forking orbotservice (again) and the two projects diverging
17:35:53 <sysrqb> for (2), creating a layer API at that fork point seems preferred
17:36:29 <sysrqb> but we have some work to do before we can make any decisions on that
17:38:38 <sysrqb> okay, next item is Report backs.
17:38:44 <sysrqb> anyone have anything to report?
17:38:48 <n8fr8h[m]> Agreed that we all want to reuse and maintain as much shared code as possible
17:39:24 <n8fr8h[m]> I think currently, there is a lot of value in having tor-android and IPtProxy separate, for use by developers building all sorts of apps, including us
17:40:07 <n8fr8h[m]> OrbotService ends up mostly being Tor+PT+VPN glue code, which is valuable for sure, but really only for general purpose VPN apps.
17:40:43 <n8fr8h[m]> i think _hc
17:41:40 <n8fr8h[m]> thought that TorService aka tor-android is the natural place to start, and along with the IPtProxy.
17:42:22 <n8fr8h[m]> right now it just seems like everything is being rewritten from scratch here though: https://gitlab.torproject.org/tpo/core/onionmasq/-/tree/main/android/ArtiToyVPN (though i understand this is a "toy" for testing arti)
17:43:05 <cyberta> right, but I agree we would build on top of TorService
17:43:12 <cyberta> and try to keep the API
17:43:24 <cyberta> but exchange arti
17:43:47 <sysrqb> ahf and dgoulet can talk more about the rationale behind using a different userspace networking stack
17:44:21 <sysrqb> I opened https://gitlab.torproject.org/tpo/applications/vpn/-/issues/14
17:44:51 <sysrqb> for tracking our discussions and decisions around TorService
17:45:05 <sysrqb> clearly there is a reason to keep TorService separate
17:45:22 <sysrqb> i'm not arguing against that if developers have a need for it
17:45:55 <sysrqb> And we have https://gitlab.torproject.org/tpo/applications/vpn/-/issues/13
17:46:10 <sysrqb> for picking up the conversation we started a couple weeks ago
17:47:12 <n8fr8h[m]> We are still sorting out our specific funding/focus under this sponsor based on where things are, but both with the China work and this, our focus is on empowering mobile developers broadly through easy to integrate components
17:47:13 <sysrqb> on the topic of how we integrate Arti - there seemed to be a few advantages and disadvantages for targetting a drop-in replacement verses taking a step back and re-imagining the design
17:47:59 <sysrqb> n8fr8h[m]: understood
17:48:20 <cyberta> we also might end up implementing sth. similar like OrbotService using the same components, but adapted to the needs of tor-vpn
17:48:22 <sysrqb> I believe we should take into account supporting current developers and future developers
17:48:26 <n8fr8h[m]> might be good to use OnionShare and Save as two different kinds of apps that you could talk through those +/- with
17:48:59 <sysrqb> Absolutely, that's a good idea
17:49:06 <n8fr8h[m]> mabye @grote would be good for that discussion on ONionShare to consider what an alternate way of using Tor-as-arti on Android would be, and then threeletteracronym for Save and OnionShare on iOS
17:49:27 <n8fr8h[m]> well, maybe not iOS yet :)
17:49:36 <sysrqb> :)
17:49:49 <n8fr8h[m]> @grote would be good, and then I can look at it from the Save for Android front
17:50:05 <n8fr8h[m]> (we do have another Save dev there but they don't work at the network layer)
17:52:38 <sysrqb> That sounds great
17:52:49 <sysrqb> we should definitely get their input
17:52:56 <cyberta> I think before we haven't decided these basic things, we cannot really write a task list here: https://gitlab.torproject.org/tpo/applications/vpn/-/issues/5
17:53:13 <sysrqb> i worry about making future integrations more difficult "just" so we support easy backward compatibility
17:53:30 <sysrqb> so i'd like to understand developers needs
17:54:48 <sysrqb> cyberta: yes, i agree
17:55:22 <sysrqb> that is roughly a task for adapting TorService
17:55:43 <cyberta> ok
17:56:17 <cyberta> that makes it a little bit easier
17:56:26 <sysrqb> i suppose tpo/applications/vpn#13 is a dependency of tpo/applications#5
17:56:39 <sysrqb> hrm. that didn't work
17:56:50 <sysrqb> https://bugs.torproject.org/tpo/applications/vpn/13 https://gitlab.torproject.org/tpo/applications/vpn/-/issues/5
17:57:15 <sysrqb> oh, i wonder if that's because the bot doesn't repeat within some time period
17:57:18 <sysrqb> in any case
17:57:52 <sysrqb> yes, and i think we're on a good track for having these discussions and involving important people/parties
17:58:14 <sysrqb> i was hoping we'd have some time to discuss assigining tickets
17:58:25 <sysrqb> but we'll do that next meeting
17:58:39 <cyberta> ok, sounds good
17:58:43 <sysrqb> in the meantime, please assign tickets to yourself and open new tickets as you see fit
17:59:11 <sysrqb> thanks for joining everyone!
17:59:21 <sysrqb> #endmeeting