16:00:02 <meskio> #startmeeting tor anti-censorship meeting
16:00:02 <MeetBot> Meeting started Thu Oct 24 16:00:02 2024 UTC.  The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:02 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:08 <meskio> nice, meetbot is back :)
16:00:11 <meskio> hello everybody!!!
16:00:14 <meskio> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:00:16 <meskio> ask me in private to give you the link of the pad to be able to edit it if you don't have it
16:00:16 <cohosh> hi
16:00:18 <meskio> I'll wait few minutes for everybody to add you've been working on and put items on the agenda
16:00:38 <onyinyang> hihi
16:00:38 <theodorsm> Hey!
16:00:44 <shelikhoo> oh nice! the meetbot is back!
16:00:46 <shelikhoo> hi~
16:00:59 <nipaton> hi
16:01:28 <meskio> I guess we can start
16:01:43 <meskio> I kept from last week the point about the snowflake broker transition
16:01:54 <meskio> shelikhoo: how is this? any news, or still waiting?
16:02:02 <shelikhoo> it is still waiting...
16:02:09 <meskio> ack, I'll remove that point then
16:02:15 <shelikhoo> yes..
16:02:29 <meskio> next topic:
16:02:31 <meskio> Adding a snowflake transport to lyrebird
16:02:33 <meskio> cohosh?
16:03:16 <cohosh> the context for this is that we have a motivation to reduce the binary size of PTs for applications
16:03:34 <cohosh> https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42607
16:03:53 <dcf1> I guess we are moving to an "everything in lyrebird" world
16:04:07 <dcf1> which is not bad, just programming to the lyrebird interfaces rather than the PT spec
16:04:25 <shelikhoo> yes, it was block last time when kcp and previous go versions are not working along with each other
16:04:27 <cohosh> yeah, it seems like it
16:04:48 <shelikhoo> and there is nothing blocking it now...
16:04:57 <cohosh> i opened a draft MR for what it would look like to add just the snowflake client: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/merge_requests/63
16:06:12 <cohosh> i didn't add any of the commandline snowflake options, it's all configurable with the SOCKS-based pt.Args
16:06:27 <shelikhoo> I wonder if proxy setting is applied correctly
16:06:31 <dcf1> that seems fine
16:06:34 <meskio> to me it looks nice as it will simplify the life of packaging the client for TorBrowser and others
16:06:35 <cohosh> ah good point shelikhoo
16:07:02 <shelikhoo> socks5 proxy setting is not something that could just work...
16:07:07 <cohosh> it also doesn't have the event logger sending things through pt.Log
16:07:17 <cohosh> so there is work to be done
16:07:26 <cohosh> those log messages have been really useful to us
16:07:34 <shelikhoo> (particularly udp socks5 part)
16:09:05 <cohosh> generally if this move sounds good to everyone, i'll work on adding proxy and event logging support :)
16:09:14 <meskio> I guess the question is if that will mean deprecating the client binary in the snowflake repo or we plan to maintain two clients
16:09:28 <shelikhoo> I think it is really nice...
16:10:13 <cohosh> i don't think we necessarily need to remove the client binary in the snowflake repo or worry about keeping feature parity between the two
16:10:30 <shelikhoo> I think we could wait to drop the client binary, as dropping it would make development more difficult
16:10:33 <cohosh> just like meek_lite and the meek client are both around
16:11:21 <meskio> ok, the client is not that big anyway, we'll see in the future
16:11:28 <shelikhoo> as it would require us debugging a dependency when debugging client features
16:11:40 <cohosh> i've also kept the snowflake server out of Lyrebird
16:12:02 <dcf1> it doesn't belong there imo
16:12:06 <cohosh> i don't see a pressing reason to implement that, since there is such an involved process with running the server anyway
16:12:12 <dcf1> same as there's no meek server in lyrebird
16:12:18 <cohosh> good point
16:12:19 <meskio> I agree the snowflake server doesn't make sense in lyrebird
16:12:39 <dcf1> it's only because the obfs-likes are so symmetric in their implementation that it's convenient to put the server in the same executable
16:12:47 <shelikhoo> yes, webtunnel server is also missing from lyrebird
16:13:04 <meskio> but I think webtunnel server will fit in lyrebird
16:13:13 <meskio> it will make the life of bridge operators easier
16:14:36 <meskio> I guess we are done with this topic
16:14:51 <shelikhoo> yes.... that is true. although it is not in todo list for now
16:14:54 <cohosh> yeah, nothing more from me. thanks!
16:15:07 <meskio> shelikhoo: sure, there is no rush there
16:15:12 <shelikhoo> yes
16:15:14 <shelikhoo> eof
16:15:35 <meskio> theodorsm: I saw pion/webrtc v4 release, is that one including your work?
16:15:45 <meskio> maybe we can start looking into integrating that...
16:16:16 <theodorsm> yes, it has some features for integrating with covert-dtls!
16:16:44 <theodorsm> I have been experimenting with the beta version, but having some issues (and not enough time to work on it)
16:16:54 <dcf1> congrats theodorsm, your hard work and attention have paid off, it's making a difference
16:17:01 <cohosh> wow that's awesome!
16:17:10 <theodorsm> Thanks all!
16:17:12 <shelikhoo> nice!!!!! awesome!
16:17:17 <shelikhoo> and thanks!!!
16:17:28 <meskio> nice
16:18:30 <meskio> any other discussion points for today?
16:18:38 <shelikhoo> eof
16:18:52 <dcf1> cohosh, what's your note about the "split broker into components" MR?
16:19:48 <cohosh> oh, i was going through MRs that were assigned to me and noticed that this has been abandoned
16:20:42 <cohosh> there are some in progress discussions
16:20:47 <dcf1> arlo had contacted me at some point and asked if he should resurrect that one
16:21:11 <cohosh> yeah, i thought maybe now that the broker is being redeployed and we're thinking about it
16:21:19 <cohosh> it's a good time to think about whether we still want this
16:21:21 <dcf1> it's ok to close imo, or ask arlo if he has short-term plans for it. I think he only stopped because there was interest/need at the time.
16:21:52 <dcf1> I still want it, but I won't have resources to work on it myself.
16:22:02 <cohosh> okay, i'll reach out to arlo
16:22:18 <dcf1> But yeah, every rendezvous method server, at least, really ought to be separated into a separate process, and not run everything in the same process.
16:22:49 <cohosh> if he has time to work on it soon, i'll leave it open but if not i'll close it and someone can feel free to reopen it later
16:23:04 <cohosh> closing doesn't mean we don't want it, and there is a significant rebase that's required anyway
16:23:09 <dcf1> sounds good
16:23:21 <cohosh> thanks
16:24:44 <meskio> on the interesting links:
16:24:59 <meskio> ValdikSS has published an OS image for vantage points: https://github.com/ValdikSS/hoogmoon-testing
16:25:21 <meskio> Tor has being release with PT version support
16:25:42 <meskio> and some uTLS for quic implementation: https://github.com/refraction-networking/uquic
16:25:44 <dcf1> the idea is that users run this when they are censored. it provides them with circumvention, and also provides remote root access to the research who gave it to them, for conducting measurements
16:25:54 <dcf1> hoogmoon that is
16:26:18 <dcf1> I have tried it myself or examined it closely. I hear there are some installations in existence.
16:26:30 <meskio> nice, it can be very useful
16:27:49 <shelikhoo> yes! nice!
16:29:31 <meskio> I guess we are done then
16:29:52 <meskio> #endmeeting