15:59:46 <shelikhoo> #startmeeting tor anti-censorship meeting
15:59:46 <shelikhoo> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:59:46 <shelikhoo> feel free to add what you've been working on and put items on the agenda
15:59:46 <MeetBot> Meeting started Thu Oct 12 15:59:46 2023 UTC.  The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:46 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:01 <meskio> hello
16:00:14 <onyinyang[m]> hello! o/
16:00:25 <shelikhoo> hi~
16:00:36 <cohosh> hi
16:05:51 <shelikhoo> okay, let's start with an announcement:
16:05:52 <shelikhoo> A poll to set a date for a 'Future of PTs' voice conversation
16:05:52 <shelikhoo> https://www.systemli.org/poll/#/poll/YRRF8K19Bq/evaluation?encryptionKey=e1f9KPaHH6z7I6uYGNQVlegHvMGB3aHJaEufGQl7
16:05:52 <shelikhoo> Times in UTC
16:06:11 <shelikhoo> the first discussion topic we have is:
16:06:12 <shelikhoo> - (Network Health) 'Running' flag for counting bridges and network size https://gitlab.torproject.org/tpo/network-health/team/-/issues/318
16:06:12 <meskio> as a follow up from last weeks discussion, let's try to agree on a date to have it over voice
16:06:32 <meskio> the running flag point was added last week
16:06:39 <meskio> was it ggus or GeKo?
16:07:04 <meskio> anyway, is a conversation we are having with the metrics team to stop using the 'Running' flag to signal if a bridge is running
16:07:13 <dcf1> hooray :)
16:07:19 <meskio> as we do support bridges without the ORPort public, and that will imply no running flag
16:07:34 <GeKo> hi
16:07:45 <meskio> hello :)
16:07:55 <meskio> GeKo: any specific questions we should discuss here about this?
16:07:56 <GeKo> i think ggus was filing the ticket and i did a bunch of investigations
16:08:19 <GeKo> so, there a different options i proposed in the ticket
16:08:25 <GeKo> about how to move forward
16:08:37 <dcf1> In the reproducible metrics guide, the "Running" flag also affects estimates of user counts, not just the estimate of the number of bridges.
16:08:47 <GeKo> which are mainly aimed at improving the relay-search side
16:08:49 <GeKo> yeah
16:09:16 <GeKo> the metrics are even harder because for those we don't take bridgestrap results into account yet at all
16:09:51 <GeKo> but it seems using bridgestrap is our best option in the longer run
16:09:57 <GeKo> did i get that right?
16:10:21 <meskio> yes, I agree
16:10:35 <meskio> either you use bridgestrap directly or we mediate it somehow from rdsys
16:10:40 <GeKo> okay. then we should think about how to make best use of it
16:10:46 <meskio> but as you already poll bridgestrap maybe better to use it directly...
16:11:06 <GeKo> because using bridgestrap results just once a day is not ideal
16:11:32 <GeKo> relay-search is centered around hourly metrics
16:11:42 <meskio> how are you polling bridgestrap? AFAIK the API is not reachable from outside localhost...
16:11:51 <GeKo> so, ideally we would get hourly bridgestrap results inputs here as well
16:12:00 <GeKo> just taking what we have on collector
16:12:09 <GeKo> which is getting updated daily at 0940UTC it seems
16:12:20 <meskio> we can reduce the cache of bridgestrap (currently 18h) to 1h, so it test every bridge at least once per hour
16:12:41 <GeKo> https://collector.torproject.org/recent/bridgestrap/
16:12:49 <GeKo> that would be nice
16:12:50 <dcf1> are descriptors from bridges that are not actually running very common? what happens if they are just all included? maybe the effect is negligible, even without filtering some out with bridgestrap etc.?
16:12:51 <meskio> ok, so bridgestrap is publishing some collector file
16:12:56 <GeKo> yeah
16:13:00 <meskio> and you need it to be published more regularly
16:13:21 <GeKo> yeah
16:13:45 <GeKo> dcf1: dunno
16:13:47 <meskio> we envision a future were bridge testing is done by a constant connection to all bridges, there was a GSOC this summer working on that, but I haven't check how far they got
16:14:06 <meskio> so we might retire bridgestrap at some point, but I'm happy to do the changes you need in the mean time
16:14:11 <trinity-1686a> fyi I'll probably start playing with https://gitlab.torproject.org/tpo/core/arti/-/issues/717 (seems relevant to bridgrstrap convo)
16:14:51 <GeKo> meskio: there are some bridgestrap bugs which might spoil things a bit
16:15:08 <GeKo> one ticket i filed and then the ordering part unresolved
16:15:50 <GeKo> https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/24#note_2948488
16:16:10 <GeKo> but those should not be blockers imo to get things changed
16:17:03 <GeKo> so, getting the results in an hourly fashion onto collector and testing hourly would be the changes i'd like to see if possible
16:17:39 <GeKo> once we are confident this is a good thing we can then tackle the larger question about what to do with our metrics on metrics.tpo
16:18:10 <GeKo> dcf1: the user count estimation relation was a good point, thanks
16:18:16 <GeKo> that's all from me
16:18:55 <meskio> trinity-1686a: yes, that one is the one I was thinking on, there was a GSOC on it, isn't it?
16:18:55 <trinity-1686a> I'm not sure, you should ask nick, I think he mentored them
16:18:55 <meskio> GeKo: let me explore bridgestrap and see how to fix this and come back to you
16:18:55 <meskio> I'll open an issue in our side for it
16:18:55 <meskio> I wonder if we'll see any implications on running bridgestrap every hour insted of every18h, but I guess I'll need to experiment with it and see
16:18:55 <meskio> as if bridgestrap is fast enought to test all bridges every 18h, maybe not
16:18:56 <shelikhoo> anything more we would like to discuss on this topic?
16:18:56 <shelikhoo> the next topic is:
16:18:56 <shelikhoo> - Armored Bridge line Spec
16:18:56 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/126#note_2954127
16:18:56 <shelikhoo> So after sometime of delay, I have finally wrote the first version of the armored bridge line spec ready for a internal review
16:18:56 <shelikhoo> it does not have any shiny features, but should be easy enough to be implemented
16:18:56 <meskio> s/every 18h/every 1h/
16:18:56 <meskio> that is all from my side
16:19:22 <GeKo> meskio: ack, thanks!
16:19:27 <shelikhoo> wired... maybe the irc connection is not stable
16:19:55 <shelikhoo> I am receiving a lot of desynchronised messages
16:20:12 <shelikhoo> I will send my lines again
16:20:19 <shelikhoo> the next topic is:
16:20:19 <shelikhoo> - Armored Bridge line Spec
16:20:19 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/126#note_2954127
16:20:19 <shelikhoo> So after sometime of delay, I have finally wrote the first version of the armored bridge line spec ready for a internal review
16:20:19 <shelikhoo> it does not have any shiny features, but should be easy enough to be implemented
16:21:11 <shelikhoo> do we wants to discuss it now, or we wants discuss it next week
16:21:24 <shelikhoo> after we have enough time to have a look at it?
16:21:46 <meskio> should the spec include details on how the URI looks like?
16:22:00 <meskio> but yes, I'll properly read it for next week
16:22:21 <shelikhoo> yes, I will edit it to have a few examples in it
16:22:34 <shelikhoo> let's discuss it further next week
16:22:48 <shelikhoo> the last topic is
16:22:49 <shelikhoo> - snowflake broker restart(deployment) needed, and deletion of ip-count-mask key
16:22:49 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40295
16:23:24 <shelikhoo> I am aware of this, and I will tag a new version of snowflake next monday and deploy it
16:23:31 <dcf1> I want the broker to stop writing to the log file so we have a finished artifact we can make public.
16:23:42 <dcf1> ok, thanks shelikhoo
16:24:15 <dcf1> on the issue I noted a potential difficulty with version control in /etc, which will have recorded the masking key.
16:26:00 <shelikhoo> yeah... we can stop recording first, and think about how to work with version control later
16:26:14 <shelikhoo> it would be possible to just amend and rebase the commits
16:26:20 <dcf1> that's what I was thinking
16:26:27 <shelikhoo> since it is not something we made public
16:26:47 <shelikhoo> so it shouldn't be that much an issue if we delay it for a little
16:27:24 <shelikhoo> okay anything more we would like to discuss on this topic?
16:27:25 <dcf1> in the worst case, if we lose all history in /etc and have to restart it, it's not a disaster imo.
16:27:30 <dcf1> no
16:28:16 <shelikhoo> anything we would like to discuss in this meeting?
16:28:25 <shelikhoo> anything more we would like to discuss in this meeting?
16:28:38 <meskio> not from my side
16:29:20 <shelikhoo> #endmeeting