16:59:00 <ahf> #startmeeting Network team meeting, 21st november 2022
16:59:00 <MeetBot> Meeting started Mon Nov 21 16:59:00 2022 UTC.  The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:00 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:59:06 <ahf> hello folks
16:59:09 <ahf> pad is at https://pad.riseup.net/p/tor-netteam-2022.1-keep
16:59:14 <nickm> hihi!
16:59:18 <Diziet> o/
16:59:36 <ahf> giving folks a few to join in
16:59:50 <nickm> eta: ping :)
16:59:54 <eta> hewwo
16:59:59 <nickm> hebbo!
17:00:45 <jnewsome> o/
17:00:57 <ahf> mike's out this week, so i think the s61 stuff is going to be very short. GeKo / hiro / jnewsome / juga, does any of you have anything for that we need to discuss?
17:01:09 <jnewsome> ahf: nope
17:01:45 <ahf> excellent, maybe the others are already skipping this meeting because mike's out - that would make sense
17:01:48 <ahf> ok good, let's get started
17:01:51 <ahf> https://gitlab.torproject.org/groups/tpo/core/-/boards
17:01:55 <ahf> how are folks doing with their board?
17:02:22 <Diziet> working off    https://gitlab.torproject.org/tpo/core/arti/-/boards/353?milestone_title=Arti%201.1.0%3A%20Anticensorship%20ready
17:02:47 <ahf> ya, makes sense to stay int he arti only board there - it is a lot less chaotic
17:03:21 <nickm> i'm chugging along
17:03:25 <Diziet> I'm slightly concerned that some of the items in "Backlog" there (ie not started) are textually large and we have some outstanding branches which we're holding them for.
17:03:38 <nickm> ?
17:03:45 <nickm> which ones
17:04:03 <GeKo> ahf: i am assuming no s61 stuff today, so, no from my side :)
17:04:07 <Diziet> arti#635 arti#623 arti#649
17:04:16 <ahf> GeKo: perfect, i thought so too, but i forgot to ask y'all before the meeting
17:04:32 <Diziet> Possibly arti#536 too, given my intended approach
17:04:45 <Diziet> Wait, no, arti#556
17:04:56 <GeKo> i am a bit confused as it's not really clear when there is s61 sync and when not but i default to "no" in thsese cases nowadays
17:05:03 <ahf> uff, glad it was not 536 there
17:05:20 <ahf> GeKo: yeah, i think we forgot to talk about that last week that mike would be out here
17:06:15 <nickm> I think we should be okay with those. We should try to take decisions on 623 (renaming) while we can, but they ought to be straightforward if done independently.
17:06:35 <nickm> And its' not a disaster if any of them has to wait till after 110. Though it would be A Bit Ugly.
17:07:26 <Diziet> I think the renamings in #623 probably go all the way up to arti-client so I would like to treat them as a blocker.
17:07:31 <nickm> For my part I think the only 1.1.0 item that we simeply couldn't delay is eta's ptmgr work, and arti#651 to make sure we know what's working.
17:07:33 <Diziet> The rest I am OK with deferring if we have to.
17:07:42 <ahf> maybe bump the rename one up to ~Next then?
17:07:59 <Diziet> ahf: Sure, willdo now
17:08:24 <Diziet> It doesn't have an assignee but mostly it's discussion; the implementation will be straightforward.
17:08:28 <nickm> Diziet: fair enough, but I would rather break compatibility on arti-client again later than delay this release to argue about renaming. So let's try to reach consensus early
17:08:39 <nickm> doing the actual renaming, once we have consensus, will be fast.
17:08:47 <Diziet> We can't actually do that though until eta's PT branch has landed (and ideally the outstanding MRs merged if we can)
17:08:49 <eta> my take on the renamings is that they're okay to break
17:09:08 <eta> it's unlikely anyone will start seriously depending on some minor internals in the time between this and the next release anyway
17:09:42 <eta> PT branch status update: still chugging along, either this evening or tomorrow middle-of-the-day for first cut :o
17:10:06 <ahf> cool
17:10:08 <nickm> hm. okay. And how much glue will we need at that point?
17:10:41 <ahf> remember nickm's out at the end of the week here and a lot of the org is afk there. i am around tho, but i am not that useful in the arti context here lol
17:10:44 <nickm> Like, will it be a ChannelFactory/TransportRegistry implementation that we just have to write the launch+install code for?
17:10:52 <eta> ideally yes
17:11:27 <Diziet> Is there a way to give us a prefix of the MR branch ?  That would let us start reviewing it.
17:11:28 <eta> well, not "ideally", I've written the ChannelFactory (well, AbstractPtMgr) impl already
17:11:32 <nickm> (FWIW I will be willing to review on thursday night or friday for 30-40 minutes if it will get you unstuck.)
17:11:59 <eta> just need to do a little reactor inside tor-ptmgr, so tomorrow is very likely
17:12:02 <eta> if not this evening
17:12:04 <Diziet> (And, I can be available on Friday morning for an hour or so if it would help.)
17:12:24 <Diziet> Could you submit the MR with the reactor stubbed out ?
17:12:48 <eta> I mean you can literally have what I've got right now, but I'd rather just do this first thing tomorrow; it won't take that long to write and clean up a bit
17:13:18 <nickm> ok. But if it goes past then let's do a draft branch with the reactor  stubbed out?
17:13:20 <eta> I think I'd most appreciate it if people could help with writing some of the glue
17:13:22 <eta> nickm: sgtm
17:13:35 <Diziet> help with glue> Sure, of course.
17:13:44 <nickm> eta: excellent, especially if you can mark missing glue with `TODO pt-client WRITEME` or such
17:14:00 <eta> will try and do that in tomorrow's cleanup pass
17:14:06 <ahf> perfect
17:14:34 <nickm> sounds like we're still on track :)
17:14:58 <ahf> let's do a sync tomorrow at 17:00 UTC on IRC as an internal arti meeting just in #tor-dev to see where we are there, yeah?
17:15:06 <Diziet> SGTM
17:15:08 <ahf> i haven't added it to nc yet, but i was hoping people can do that
17:15:13 <nickm> wfm
17:15:22 <ahf> eta: works for you too?
17:15:50 <eta> we already had a meeting in the nc for that time anyway I think :o
17:15:52 <eta> (yes, wfm)
17:15:52 <Diziet> eta: Can I ask a question?  Does your brach touch code that mentions `BridgeConfig` at all ?  I'm hoping not.
17:16:12 <Diziet> If so then I can do arti#635 without causing conflicts
17:16:24 <ahf> only for last week, so every 14 day, not the one this week
17:16:36 <eta> Diziet: it does not
17:16:39 <Diziet> Cool.
17:16:43 <eta> ahf: interesting, my calendar sync must be behind
17:16:49 <Diziet> nickm: OK with me taking #635 then ?
17:17:20 <ahf> maybe i am wrong then - gonna look after :D
17:17:26 <ahf> okay, i can go to the next item in the agenda?
17:17:46 <nickm> Diziet: go for it
17:17:52 <nickm> ahf: okay w me :)
17:18:02 <ahf> dgoulet: anything on releases in c-tor land?
17:18:26 <dgoulet> not at all for now :)
17:18:35 <ahf> \o/
17:19:10 <ahf> nothing incoming from other teams. we got some stuff from the relay ops meeting that folks there was interested in, but david, geko and i can chat about that
17:19:21 <ahf> i added a label to try to keep track of what we get requested from the relay ops folks too
17:19:31 <ahf> david is already on one of the tickets
17:20:13 <ahf> no announcements, but we have some discussion items that seems mostly related to the arti gang
17:20:23 <ahf> Diziet: i don't know if these go out after the conversation we have above? it seems to overlap a bit
17:20:40 <ahf> * [2022-11-21] [Diziet] Get opinions from rest of network team re arti#627 "guardmgr should log  bridge/pt connection status"
17:20:41 <ahf> https://gitlab.torproject.org/tpo/core/arti/-/issues/627
17:20:56 <Diziet> I think we still want opinions about that.
17:21:31 <Diziet> The basic problem is that I reckon the useability of the bridge stuff is rather poor, since you configure N bridges and the logs just say "bridge [scrubbed] is hopeless; bridge [scrubbed] is working nicely"
17:21:48 <ahf> i am reading it
17:21:51 <Diziet> AIUI C Tor does the same but presumably the control port lets you see what's going on ?
17:23:21 <ahf> pt connection status here is not the PT `STATUS` protocol message, right?
17:23:36 <Diziet> No
17:23:39 <ahf> good
17:24:03 <Diziet> High-level user-facing info "this PT is :-)" "this PT is :-("
17:24:05 <ahf> i think it is a good idea to have some log feedback here, especially given that arti is pretty new and the integrators who eventually will have to work with this will be used to c tor's behavior here
17:24:10 <ahf> yeah
17:24:23 <ahf> i think logging it for now is fine, then we can later look at if we need to have some api's for this
17:24:36 <Diziet> So we do have messages; the issue is that you can't tell *which* bridge line they relate to
17:25:09 <Diziet> You can turn off log scrubbing but that's not a good idea.  And you don't want to leak the info that would be logged in an unscrubbed message.
17:25:23 <Diziet> I mean, the user doesn't want to, so we need to not provide a footgun.
17:25:46 <ahf> could you add a tag to the bridge line?
17:25:48 <Diziet> If logging these things in a way that makes it hard to relate messages to configured bridges is fine, then we can defer the ticket.
17:25:54 <ahf> tag=pt1, then it shows the tag in the log?
17:26:13 <Diziet> Nice idea but bridge lines are an interchange format so we'd have to get creative with the syntax
17:26:26 <Diziet> We could probably include the index in the config "bridge line #1"
17:26:31 <ahf> ahhhh, shit, of course, you need to use the bridge format used elsewhere /o\
17:26:37 <ahf> yeah, config line is a good idea too
17:26:49 <Diziet> Is this a blocker for 1.1.0 ?
17:26:51 <ahf> or relatively to the other bridge lines, yeah, so it's bridge #1 is the first seen
17:26:53 <ahf> i don't think so
17:26:57 <Diziet> \o/
17:26:58 <ahf> it's a dx/ux thing i'd say
17:27:29 <ahf> i hope nickm/eta agrees here, the pt debugability in C tor was a bit a pain in the older days of C tor, so i may just be bouncing off from that
17:27:31 <Diziet> OK.  If no-one has a dissenting opinion I will de-milestone the ticket and self-assign and we can do it later
17:27:41 <ahf> oki, cool with me
17:27:42 <nickm> In other news I should hve this obsoleted soon with arti#648, if I have time
17:28:39 <ahf> cool
17:29:03 <Diziet> OK thanks.
17:29:04 <ahf> next item is:
17:29:04 <ahf> * [2022-11-21] [Diziet] arti: next steps (schedule discussion?) re arti#623 (renamings)
17:29:05 <ahf> https://gitlab.torproject.org/tpo/core/arti/-/issues/623
17:29:10 <Diziet> We more or less did that.
17:29:11 <ahf> that was already up, no?
17:29:14 <ahf> yeah
17:29:26 <ahf> last item is:
17:29:27 <ahf> * [2022-11-21] [Diziet] arti: review status of 1.1.0 tickets? ditch some? what's the plan?
17:29:37 <Diziet> Wait, this is backwards.
17:29:42 <Diziet> Fine, that's done.
17:29:48 <ahf> perfect
17:29:54 <ahf> okay, arti gang we can sync up tomorrow at 17 utc
17:29:55 <Diziet> nickm: Did you want to chat about arti#623 in the ticket ?
17:30:00 <ahf> i don't have anything else for today's meeting
17:30:07 <ahf> does anybody else have something we need to go over?
17:30:10 <nickm> Diziet: yes, i think that's fine.  eta can weigh in too?
17:30:12 <Diziet> Sorry to non-arti folks for taking up your time
17:30:16 <Diziet> eta: ^ quite so
17:30:35 <ahf> i think the non-arti people are in the bar already
17:30:43 <Diziet> Good-oh
17:30:45 <ahf> let's call it then <3
17:30:46 <ahf> thanks all!
17:30:48 <ahf> #endmeeting