16:00:12 <cohosh> #startmeeting tor anti-censorship meeting
16:00:12 <MeetBot> Meeting started Thu Jun  3 16:00:12 2021 UTC.  The chair is cohosh. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:12 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:22 <gaba> hi!
16:00:31 <meskio> hello o/
16:00:33 <cohosh> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
16:00:51 <cohosh> feel free to add items to the agenda
16:01:57 <meskio> I will like to add a point about releasing snowflake, but I'm not sure where to do that
16:02:11 <meskio> discussion?
16:02:28 <cohosh> yeah discussion sounds like a good place for that
16:02:36 <meskio> done :)
16:03:28 <cohosh> cool :) meskio do you want to go ahead and lead that discussion now?
16:04:25 <meskio> sure
16:04:42 <meskio> for the debian package will be useful to have proper snowflake releases
16:05:00 <meskio> and I guess it might also good for deployment
16:05:31 <meskio> I don't think a release requires much more than a tag in the repo with a number, but we should define the release process
16:05:54 <meskio> I would assume numbering should follow semantic versioning (as we do in other projects more or less)
16:06:14 <meskio> how do people feel about producing releases?
16:06:32 <meskio> (let's first if we are all good with it before discussing details on how to do them)
16:06:36 <cohosh> yeah Go tags will be nice for other projects that want to use the new snowflake libraries we just made for snowflake#40036
16:06:44 <cohosh> err git repo tags
16:06:51 <cohosh> in combination with how go modules work
16:07:10 <meskio> +1
16:07:26 <gaba> can we document the process of releasing somewhere if that start happening?
16:07:52 <meskio> yes, we should do that, bridgedb does have a document that we can use as inspiration for snowflake one
16:08:43 <cohosh> we also have a process defined in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/blob/main/README.md for the webextension
16:08:54 <arma2> including making tarballs and we have to pick somebody who will sign with their gpg key? :)
16:09:21 <arma2> (debian and other distros might even enjoy the tarballs rather than the git tags. or maybe i'm thinking of the bsd packaging world.)
16:09:27 <meskio> mmm, for debian packaging and deployment we might not care so much about tarballs
16:09:36 <meskio> modern debian packaging tools can understand git tags
16:09:46 <meskio> but gpg signing the git tags is recommended
16:09:59 <meskio> modern debian packaging tools == git-buildpackage
16:10:20 <arma2> ok. i guess part of documenting the process is deciding how far down the 'release' road to go.
16:10:25 <cohosh> let's keep it as simple as possible to start and just add things as we need them
16:10:30 <gaba> +1
16:10:32 <arma2> makes sense
16:10:38 <cohosh> so for now if all we need is git tags, let's just do that
16:10:38 <meskio> +1
16:11:07 <cohosh> and with go modules at least i think we should start with major version 1 instead of 0
16:11:31 <meskio> 1.0.0?
16:11:37 <cohosh> sounds good to me :)
16:12:13 <meskio> might be nice to do have simple changelogs, they can be done directly in the git tag
16:12:19 <meskio> we might not need a changelog file
16:12:50 <cohosh> yeah, i'm okay with that
16:13:17 <arma2> when you go to announce your releases, you may realize that having a changelog file to show people helps them know what changed
16:13:55 <arma2> but 'keep it simple and see if that's really true' is a legit strategy too :)
16:14:21 <meskio> if you go to the tags list in gitlab you will get something like a changelog, but I'm ok with having a proper changelog file
16:14:37 <cohosh> do we need it for debian packaging?
16:14:46 <meskio> not really
16:15:13 <cohosh> okay i don't feel strongly, but prefer the simplest option in that case
16:15:26 <cohosh> we already do something like a changelog in the monthly reports
16:15:37 <cohosh> and as you mentioned, the git history provides that as well
16:15:54 <cohosh> we can always add one later
16:16:05 <meskio> I find changelogs useful as a user to see how things have improved, but I don't care if they come as a git anotation or a changelog file
16:16:23 <meskio> anyway, the first release don't really need anything in the changelog
16:16:32 <cohosh> heh, true :)
16:17:01 <meskio> with git I was thinking on adding an anotation with 'git tag -a'
16:17:22 <cohosh> ah I see
16:17:30 <cohosh> okay that sounds good to me
16:17:53 <meskio> anyway, I feel we are bikesheding here
16:18:19 <cohosh> yeah i think we can call this good
16:18:29 <meskio> +1
16:18:40 <cohosh> any more discussion for today?
16:18:59 <cohosh> we have our may monthly report in progress here: https://pad.riseup.net/p/gzx2ELX_6sFoh_8Xsw77
16:19:37 <cohosh> i started adding some things but wasn't very thorough yet so if you have time, please take a look and add things you've worked on in the last month
16:19:49 <gaba> it would be good to announce the plans for conjure somewhere cohosh
16:20:08 <gaba> announcement in the pad for this meeting or in the report
16:20:14 <cohosh> oh right
16:20:19 <cohosh> okay i can do both
16:20:31 <gaba> thanks
16:20:58 <cohosh> as gaba said, we're starting to work on a conjure PT for Tor
16:20:59 <arma2> is 'new developer' a legit news item for may? :)
16:21:25 <cohosh> we've been talking with eric wustrow about using their existing relay station deployment
16:22:20 <cohosh> here's some preliminary notes: https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/9
16:23:20 <dcf1> Is this the same existing deployment as was described in https://censorbib.nymity.ch/#VanderSloot2020a "Running Refraction Networking for Real"?
16:23:28 <cohosh> dcf1: yup!
16:23:37 <dcf1> Which in that paper was using Psiphon with TapDance, but now apparently uses Conjure?
16:23:51 <arma2> i think they currently do both in practice (tapdance and conjure)
16:23:57 <dcf1> ok
16:24:06 <cohosh> yeah, my understanding is that they modified the tapdance deployment to also do conjure
16:24:20 <agix> hi
16:24:25 <cohosh> and that psiphon will be switching to primarily using conjure since it's more performant
16:25:10 <cohosh> and tap dance is becoming more of a "signaling" protocol much like we'll have multiple signaling channels for snowflake
16:28:08 <cohosh> okay, anyone need reviews or help with what they're working on?
16:28:22 <arma2> and for extra fun, apparently they wanted to use obfs4 as one of their transports, but yawning's switch to gpl made it too cumbersome. so, we could be their first obfs4 try, because we don't mind gpl. also we could take that opportunity to realize that gpl is cumbersome for people.
16:32:11 <cohosh> alright, i'll end the meeting soon
16:33:03 <cohosh> #endmeeting