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