16:59:00 #startmeeting Network team meeting, 21st november 2022 16:59:00 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:06 hello folks 16:59:09 pad is at https://pad.riseup.net/p/tor-netteam-2022.1-keep 16:59:14 hihi! 16:59:18 o/ 16:59:36 giving folks a few to join in 16:59:50 eta: ping :) 16:59:54 hewwo 16:59:59 hebbo! 17:00:45 o/ 17:00:57 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 ahf: nope 17:01:45 excellent, maybe the others are already skipping this meeting because mike's out - that would make sense 17:01:48 ok good, let's get started 17:01:51 https://gitlab.torproject.org/groups/tpo/core/-/boards 17:01:55 how are folks doing with their board? 17:02:22 working off https://gitlab.torproject.org/tpo/core/arti/-/boards/353?milestone_title=Arti%201.1.0%3A%20Anticensorship%20ready 17:02:47 ya, makes sense to stay int he arti only board there - it is a lot less chaotic 17:03:21 i'm chugging along 17:03:25 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 ? 17:03:45 which ones 17:04:03 ahf: i am assuming no s61 stuff today, so, no from my side :) 17:04:07 arti#635 arti#623 arti#649 17:04:16 GeKo: perfect, i thought so too, but i forgot to ask y'all before the meeting 17:04:32 Possibly arti#536 too, given my intended approach 17:04:45 Wait, no, arti#556 17:04:56 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 uff, glad it was not 536 there 17:05:20 GeKo: yeah, i think we forgot to talk about that last week that mike would be out here 17:06:15 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 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 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 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 The rest I am OK with deferring if we have to. 17:07:42 maybe bump the rename one up to ~Next then? 17:07:59 ahf: Sure, willdo now 17:08:24 It doesn't have an assignee but mostly it's discussion; the implementation will be straightforward. 17:08:28 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 doing the actual renaming, once we have consensus, will be fast. 17:08:47 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 my take on the renamings is that they're okay to break 17:09:08 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 PT branch status update: still chugging along, either this evening or tomorrow middle-of-the-day for first cut :o 17:10:06 cool 17:10:08 hm. okay. And how much glue will we need at that point? 17:10:41 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 Like, will it be a ChannelFactory/TransportRegistry implementation that we just have to write the launch+install code for? 17:10:52 ideally yes 17:11:27 Is there a way to give us a prefix of the MR branch ? That would let us start reviewing it. 17:11:28 well, not "ideally", I've written the ChannelFactory (well, AbstractPtMgr) impl already 17:11:32 (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 just need to do a little reactor inside tor-ptmgr, so tomorrow is very likely 17:12:02 if not this evening 17:12:04 (And, I can be available on Friday morning for an hour or so if it would help.) 17:12:24 Could you submit the MR with the reactor stubbed out ? 17:12:48 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 ok. But if it goes past then let's do a draft branch with the reactor stubbed out? 17:13:20 I think I'd most appreciate it if people could help with writing some of the glue 17:13:22 nickm: sgtm 17:13:35 help with glue> Sure, of course. 17:13:44 eta: excellent, especially if you can mark missing glue with `TODO pt-client WRITEME` or such 17:14:00 will try and do that in tomorrow's cleanup pass 17:14:06 perfect 17:14:34 sounds like we're still on track :) 17:14:58 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 SGTM 17:15:08 i haven't added it to nc yet, but i was hoping people can do that 17:15:13 wfm 17:15:22 eta: works for you too? 17:15:50 we already had a meeting in the nc for that time anyway I think :o 17:15:52 (yes, wfm) 17:15:52 eta: Can I ask a question? Does your brach touch code that mentions `BridgeConfig` at all ? I'm hoping not. 17:16:12 If so then I can do arti#635 without causing conflicts 17:16:24 only for last week, so every 14 day, not the one this week 17:16:36 Diziet: it does not 17:16:39 Cool. 17:16:43 ahf: interesting, my calendar sync must be behind 17:16:49 nickm: OK with me taking #635 then ? 17:17:20 maybe i am wrong then - gonna look after :D 17:17:26 okay, i can go to the next item in the agenda? 17:17:46 Diziet: go for it 17:17:52 ahf: okay w me :) 17:18:02 dgoulet: anything on releases in c-tor land? 17:18:26 not at all for now :) 17:18:35 \o/ 17:19:10 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 i added a label to try to keep track of what we get requested from the relay ops folks too 17:19:31 david is already on one of the tickets 17:20:13 no announcements, but we have some discussion items that seems mostly related to the arti gang 17:20:23 Diziet: i don't know if these go out after the conversation we have above? it seems to overlap a bit 17:20:40 * [2022-11-21] [Diziet] Get opinions from rest of network team re arti#627 "guardmgr should log bridge/pt connection status" 17:20:41 https://gitlab.torproject.org/tpo/core/arti/-/issues/627 17:20:56 I think we still want opinions about that. 17:21:31 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 i am reading it 17:21:51 AIUI C Tor does the same but presumably the control port lets you see what's going on ? 17:23:21 pt connection status here is not the PT `STATUS` protocol message, right? 17:23:36 No 17:23:39 good 17:24:03 High-level user-facing info "this PT is :-)" "this PT is :-(" 17:24:05 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 yeah 17:24:23 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 So we do have messages; the issue is that you can't tell *which* bridge line they relate to 17:25:09 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 I mean, the user doesn't want to, so we need to not provide a footgun. 17:25:46 could you add a tag to the bridge line? 17:25:48 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 tag=pt1, then it shows the tag in the log? 17:26:13 Nice idea but bridge lines are an interchange format so we'd have to get creative with the syntax 17:26:26 We could probably include the index in the config "bridge line #1" 17:26:31 ahhhh, shit, of course, you need to use the bridge format used elsewhere /o\ 17:26:37 yeah, config line is a good idea too 17:26:49 Is this a blocker for 1.1.0 ? 17:26:51 or relatively to the other bridge lines, yeah, so it's bridge #1 is the first seen 17:26:53 i don't think so 17:26:57 \o/ 17:26:58 it's a dx/ux thing i'd say 17:27:29 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 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 oki, cool with me 17:27:42 In other news I should hve this obsoleted soon with arti#648, if I have time 17:28:39 cool 17:29:03 OK thanks. 17:29:04 next item is: 17:29:04 * [2022-11-21] [Diziet] arti: next steps (schedule discussion?) re arti#623 (renamings) 17:29:05 https://gitlab.torproject.org/tpo/core/arti/-/issues/623 17:29:10 We more or less did that. 17:29:11 that was already up, no? 17:29:14 yeah 17:29:26 last item is: 17:29:27 * [2022-11-21] [Diziet] arti: review status of 1.1.0 tickets? ditch some? what's the plan? 17:29:37 Wait, this is backwards. 17:29:42 Fine, that's done. 17:29:48 perfect 17:29:54 okay, arti gang we can sync up tomorrow at 17 utc 17:29:55 nickm: Did you want to chat about arti#623 in the ticket ? 17:30:00 i don't have anything else for today's meeting 17:30:07 does anybody else have something we need to go over? 17:30:10 Diziet: yes, i think that's fine. eta can weigh in too? 17:30:12 Sorry to non-arti folks for taking up your time 17:30:16 eta: ^ quite so 17:30:35 i think the non-arti people are in the bar already 17:30:43 Good-oh 17:30:45 let's call it then <3 17:30:46 thanks all! 17:30:48 #endmeeting