16:01:07 <cohosh> #startmeeting anti-censorship team meeting
16:01:07 <MeetBot> Meeting started Thu Mar 19 16:01:07 2026 UTC.  The chair is cohosh. Information about MeetBot at https://wiki.debian.org/MeetBot.
16:01:07 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:01:12 <gaba> hi
16:01:25 <dcf1> hi
16:01:30 <cohosh> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:01:39 <Shelikhoo[mds]> hi~ I can hold the meeting if necessary
16:02:18 <cohosh> looks like people are adding topics so i'll wait a few mins
16:03:00 <MeetBot> Shelikhoo[mds]: Error: Can't start another meeting, one is in progress.
16:03:00 <Shelikhoo[mds]> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:03:00 <Shelikhoo[mds]> editable link available on request
16:03:38 <cohosh> Shelikhoo[mds]: i already started it
16:04:31 <cohosh> looks like the stun server topic is sorted, there's just an update from Shelikhoo[mds] that we've added new servers and are monitoring metrics
16:04:35 <cohosh> Shelikhoo[mds]: anything else to add?
16:04:45 <Shelikhoo[mds]> okay I know what happened, \m\e\s\k\i\o and \o\n\y\i\n\y\a\n\g is AFK
16:04:47 <Shelikhoo[mds]> hi~
16:05:15 <Shelikhoo[mds]> sorry I didn't see you and started the meeting already
16:05:42 <Shelikhoo[mds]> but in anycase the meeting bot is also afk today
16:05:52 <cohosh> no it's working
16:06:18 <cohosh> at least from what i can see
16:06:27 <gaba> yes, it is working when cohosh started it
16:06:29 <Shelikhoo[mds]> yes, the stun server is working
16:06:53 <Shelikhoo[mds]> and no major change in the metrics is observed
16:06:55 <cohosh> great
16:07:07 <cohosh> thanks
16:07:15 <cohosh> next topic is: Release schedule planning for containers
16:07:32 <Shelikhoo[mds]> yes, we can wait maybe a week and start getting the update to the tor browser
16:07:49 <Shelikhoo[mds]> that is all the updates on that topic from me
16:08:19 <Shelikhoo[mds]> yes, some users are reporting that they see webtunnel container didn't get an update for too long
16:08:37 <Shelikhoo[mds]> I have started to tag a new version and release a new container image
16:09:12 <Shelikhoo[mds]> it might make sense to have a policy to release a new version once in a while even if there is no update from the code itself
16:09:33 <Shelikhoo[mds]> as the container image need an update to catch up with dependencies update
16:11:21 <Shelikhoo[mds]> do we wants to set a schedule like once every 3 month, to update new versions
16:11:55 <cohosh> 3 months seems doable
16:11:58 <Shelikhoo[mds]> (waiting for response...)
16:12:16 <cohosh> the snowflake container update is automatic as part of pushing to main right?
16:12:47 <cohosh> i was just looking at the webtunnel commit history to see if this makes sense for us to do as part of CI
16:12:55 <Shelikhoo[mds]> when we push to main, the "unstable" version get updated
16:13:24 <Shelikhoo[mds]> but the stable/latest version do require a manual release
16:13:30 <Shelikhoo[mds]> with a new version number
16:13:39 <cohosh> ah i see
16:15:08 <cohosh> if it has to be manual, is there a way to schedule the creation of gitlab issues at least?
16:15:25 <Shelikhoo[mds]> we can maybe have a list of project we wants to add to this "regular maintenance update list", and every 3 month, we check each of them to see if we wants to create a maintenance release
16:16:12 <cohosh> i'm willing to try it
16:16:53 <Shelikhoo[mds]> yeah, I think I can write an issue to track this
16:17:28 <Shelikhoo[mds]> but the target would be creating a maintenance release every 3 month, if there is no other release in between
16:17:43 <cohosh> we should in general be more willing to tag new versions, but the webtunnel code is shockingly stable
16:18:32 <Shelikhoo[mds]> our improvement is mostly client side inside lyrebird
16:19:04 <Shelikhoo[mds]> as for server side improvement, there is no funded grant to do that yet
16:19:45 <Shelikhoo[mds]> there are things like h2 or h3 support we wants to create
16:20:08 <Shelikhoo[mds]> but it was not funded yet
16:20:16 <Shelikhoo[mds]> eof from me on this topic
16:20:23 <cohosh> ok thanks Shelikhoo[mds]
16:20:32 <cohosh> anything else for today?
16:21:09 <dcf1> I have no results to report yet, but
16:21:27 <dcf1> I started working with another person to explore and prototype the idea of rateless erasure codes for rendezvous
16:21:32 <dcf1> https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Research-ideas?version_id=a9b4e5f83ecb7703ea84988629f235ea4acc20f7&version_number=11#rateless-erasure-codes-for-rendezvous-over-small-fragments
16:22:05 <Shelikhoo[mds]> nice!
16:22:06 <cohosh> awesome!
16:22:47 <Shelikhoo[mds]> actually there can be a small ad for my toy project...
16:22:48 <Shelikhoo[mds]> a small ad for my recently vibe improved dtls encrypted, rateless forward error correction(with raptorQ support bundled in) based file transfer tool. It is designed to work with network with constant packet loss(not related to local traffic load) and high bandwidth, and send files by sending files and its repair shards at constant rate regardless the amount of packet loss to transfer file faster than traditional tcp based connection.
16:22:48 <Shelikhoo[mds]> https://github.com/xiaokangwang/ai_generated_jk67h82o1rztv8zgtaw4za1u24ssz6k7be4f/tree/dev-fastTransferd-13uju36sy2qzr4t857dd1yy4jlhtx5ohk500 (no discussion needed)
16:23:27 <Shelikhoo[mds]> basically after dcf bring up this topic, I updated my toy project to play around rateless forward error correction
16:23:43 <dcf1> aha, interesting
16:23:52 <Shelikhoo[mds]> no more to add
16:25:44 <cohosh> okay, nice, i think that's it for the meeting today
16:25:47 <cohosh> thanks everyone!
16:25:55 <cohosh> #endmeeting