22:59:21 <ahf> #startmeeting snowflake network team + friends kick off 28/11 2018
22:59:21 <MeetBot> Meeting started Tue Nov 27 22:59:21 2018 UTC.  The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:59:21 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:59:31 <ahf> who is here? :-)
22:59:41 <catalyst> hi
23:00:03 <antonela> hello
23:00:05 <nickm> hihi
23:00:27 <ahf> so we have a lot of sponsor 19/snowflake tasks on the network team roadmap, which we should begin with in december
23:00:36 <ahf> at the same time we are closing down the s8 tasks
23:01:02 <ahf> i think it would be good to figure out what our goals are for december up to our feature freeze for 0.4.0 in january
23:01:20 <gaba> hey, is there a meeting here right now?
23:01:25 <ahf> yep
23:01:28 <gaba> oops, sorry
23:01:33 <ahf> just started it :-)
23:01:41 <gaba> I had my scrollback into other meeting in this channel
23:01:44 <gaba> not sure why :P
23:01:46 <ahf> ahhh!
23:01:57 <ahf> do you agree with the lines i wrote above you?
23:02:01 <teor> hi
23:02:05 <nickm> hi teor !
23:02:06 <ahf> o/ teor
23:02:28 <teor> hi all
23:02:38 <gaba> hi! yes, we also wants to clarify the works that needs to be done for snowflake, where we are at
23:03:19 <ahf> have others from the network team had a chance to try running with snowflake so far? tried to build it? tried to use it? maybe looked a bit at the code?
23:03:36 <nickm> I've read the design document, and the paper, and the thesis chapter...
23:03:43 <ahf> ok, cool!
23:03:46 <nickm> and then I got sucked into reading about What Is WebRTC Actually
23:04:11 <ahf> yeah, that was how i started too. didn't look at the thesis chapter though
23:04:18 <gaba> cool
23:04:21 <ahf> https://trac.torproject.org/projects/tor/wiki/doc/Snowflake is a very good site to get references to all of this
23:04:50 <nickm> I found the "technical writeup" link there very helpful
23:04:55 <ahf> source code is at https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/ and follows very standard go installation procedures
23:05:29 <ahf> https://github.com/keroserene/snowflake seems to be in sync too if you are more into github
23:05:56 <ahf> i don't think the javascript parts are that important for us to look at in the beginning
23:07:03 <ahf> the go webrtc component had some troubles on my machines at first with building, but i think that was fixed after an i updated it. i have only tried on linux so far, not on macos
23:07:49 <ahf> who is going to be interested in working on these things when we get to december ? and who will have time?
23:08:02 <ahf> i'd quite like to split my december between this and whatever remains with s8 at that time
23:08:08 <nickm> I might have some time, but I don't know yet.
23:08:11 <nickm> I hope I do
23:08:25 <gaba> One more thing that would be good from this meeting is to check on estimations in the issues in the roadmap and add tickets if possible or commit to add tickets to the issues there.
23:08:28 <teor> I think I will have to focus on PrivCount, but I might have some leftover time
23:08:45 <ahf> gaba: agreed, i also think many of them are very abstract
23:08:54 <ahf> and we might end up going into a rabbithole with some of them
23:09:13 <nickm> stepping back, I think we should look at each of the roadmapped deliverables and ask two questions:
23:09:19 <ahf> yep
23:09:21 <gaba> teor, does the issue "Make sure Snowflake bridges publish the right stats (country count, etc)" is related?
23:09:24 <nickm> * is this standing in the way of snowflake deployment
23:09:36 <gaba> yes
23:09:43 <nickm> * if not, does it help users significantly
23:09:55 <nickm> and I think maybe we should prioritize snowflake deployment, if that's our goal
23:09:58 <ahf> yes, good ones
23:10:07 <gaba> ok
23:10:20 <ahf> this means we can postpone the alternative PT design spec+implementation tasks till *after* january?
23:10:27 <ahf> do we agree on that?
23:10:38 <nickm> ahf: IMO yes, though we can start earlier
23:10:45 <nickm> I bet we'll get ideas as we think about snowflake
23:10:57 <ahf> they are marked as 5-20 points and i think they are the most abtract ones. we have the httpsproxy one we could use
23:11:00 <ahf> yes, i think that too
23:11:22 * arma1 reads backlog
23:11:38 <ahf> ok, marked them in our roadmap
23:11:46 <ahf> we have a bridgedb task
23:11:57 <nickm> bridgedb seems orthogonal to snowflake, to me
23:12:01 <ahf> which i think could need some love, and i think sysrqb have become the maintainer of that
23:12:23 <ahf> nickm: what does that mean in this context? that you think that part can wait?
23:12:47 <ahf> arma1: o/
23:13:00 <nickm> I mean that I think that snowflake and bridgedb are independent, IIUC.  Improvments to either one will help users.
23:13:04 <nickm> I think we could work on them in parallel
23:13:18 <ahf> right
23:13:19 <nickm> Unless I'm mistaken and snowflake obsoletes bridgedb or something?  I don't think it does
23:13:49 <teor> I don't think snowflake needs bridgedb
23:13:53 <gaba> yes, and bridgedb is the other thing for the new anticensorship team
23:14:15 <ahf> it doesn't need it, no, unless we want to use bridgedb to find alternative brokers
23:14:18 <teor> Actually, that was one of my questions
23:14:32 <arma1> snowflake has its own 'distributor' or 'broker' which is equivalent to its bridgedb
23:14:33 <teor> How are we going to make each component of the snowflake system redundant?
23:14:53 <ahf> arma1: yeah, but is the plan to use bridgedb to find brokers? or?
23:14:56 <teor> That's not quite true
23:15:11 <arma1> ahf: no, the initial plan is to hard-code a broker (or two i guess) into the snowflake client
23:15:36 <teor> Ideally, we want multiple brokers, bridges, domain fronts, and STUN/TURN servers in the snowflake system
23:15:45 <ahf> yeah, that is what you do today if you want to run it, you just specify one and a domain to front against
23:15:57 <nickm> One thing that concerns me about snowflake is that anybody can sign up as a snowflake, and if you do, you get to enumerate clients and the bridges they use.  Is that right?
23:15:59 <ahf> teor: i agree about that, that has been one of the parts i've thought we should aim for too
23:16:30 <arma1> nickm: in the current design, there are only a handful of bridges that all the snowflake users head to.
23:16:36 <ahf> nickm: yeah, you can quickly get a view of the state for the given broker
23:16:48 <arma1> that is, "many censored users <-> many snowflakes <-> a couple of entry points into the tor network"
23:17:09 <teor> But the snowflakes learn client IP addresses
23:17:12 <nickm> ok.  and censored users select these bridges from a list that the broker gives them?
23:17:43 <arma1> nickm: i'm not sure. i think it might instead be that censored users get passed to a bridge by the snowflake, and they should be happy with the bridge they get.
23:17:50 <ahf> yes, and rendevouz with them, possibly using the stun/nat punching services
23:18:04 <teor> uhh, hang on
23:18:27 <ahf> ack
23:18:28 <nickm> I'm not sure why we're using bridges here.  Could the snowflake not just connect to the tor network directly?
23:18:32 <teor> the tor clients connect to the snowflake proxy, and the snowflake proxy connects to the brisge
23:18:49 <ahf> nickm: the snowflake cannot make TCP connections
23:18:53 <nickm> ah
23:18:54 <arma1> nickm: the snowflake is just some javascript in a browser
23:18:58 <ahf> nickm: it's a browser, so it uses websocket
23:19:01 <arma1> until we have a tor client in javascript in a browser, no :)
23:19:10 <nickm> so how does it connect to the bridge?
23:19:10 <ahf> or we do a WebSocketORPort 8)
23:19:40 <arma1> nickm: the bridge runs a server-side pluggable transport, and the snowflake talks to it using a web protocol
23:19:43 <ahf> via websocket
23:19:47 <nickm> ah
23:20:00 <ahf> which is HTTP + a handshake + a framing protocol
23:20:02 <nickm> clever
23:20:18 <ahf> yes, it is very neat
23:20:34 <teor> So how are we going to make each of the components redundant?
23:20:48 <ahf> so for deployment we also need to get some people to run these websocket bridges/relays/whatever we call them
23:21:01 <arma1> ahf: i assume there is one running right now, probably by dcf
23:21:11 <nickm> we could have multiple brokers by just shipping a list of several of them, and having the snowflake proxies and the clients just pick one at random
23:21:14 <teor> What is in a snowflake PT line?
23:21:28 <ahf> arma1: are you mixing broker with this now? there is a broker running yeah, hopefully there is more than one bridge?
23:21:47 <arma1> ahf: i would not be surprised if there is one bridge, run by dcf. :)
23:21:47 <ahf> teor: broker + domain fronting name + stun server
23:22:20 <nickm> each broker can have its own domain fronting; each broker can dynamically manage a list of STUN servers
23:22:22 <teor> Ok, so we can get redundancy on those 3 components by distributing 2 or more bridge lines
23:22:40 <nickm> (by "can" i mean "could in principle")
23:22:46 <teor> and then we make each broker use a separate bridge
23:22:52 <ahf> ClientTransportPlugin snowflake exec ./client -url https://snowflake-broker.azureedge.net/ -front ajax.aspnetcdn.com -ice stun:stun.l.google.com:19302 -max 3
23:22:55 <ahf> is how it looks
23:22:56 <catalyst> how do the snowflake proxies know which broker to contact to offer proxy services?
23:22:56 <nickm> teor: or set of bridges
23:23:11 <teor> indeed
23:23:12 <ahf> catalyst: they specify a broker too i believe
23:23:35 <teor> What do we do now domain fronting is dead?
23:23:43 <catalyst> might we run into some scaling problems recruiting proxies if there are multiple brokers?
23:23:43 <arma1> the snowflakes go to whichever broker is listed in the javascript they get
23:23:52 <ahf> so, the idea behind this is that domain fronting was a problem because it used a lot of traffic i think
23:24:04 <ahf> with snowflake it uses not a lot of traffic because it's just to meet one other client that works
23:24:13 <ahf> then you switch over to speaking webrtc
23:24:18 <arma1> teor: (a) domain fronting isn't dead, it still works on azure, and also it still secretly works on amazon as long as you're not loud, i hear. (b) there are two ideas for using AMP or amazon-messaging-something instead.
23:24:21 <ahf> but it is a valid question i think if this gets users
23:24:25 <ahf> (many users)
23:24:42 <teor> 2x redundancy is not great, I think we should aim for 3x
23:24:46 <nickm> I wonder if we want a snowflake proxy implementation that _doesn't_ make you run it in a browser.  Personally I'd find that easier to run.
23:24:59 <teor> Also easier for testing
23:24:59 <arma1> nickm: yes, a headless snowflake. there's a ticket for it.
23:25:04 <nickm> ack
23:25:11 <ahf> there is a ticket for headless snowflake and a ticket for a browser plugin
23:25:13 <ahf> a webextension
23:25:32 <ahf> so that it always runs in your browser if you opt in to it and install the plug-in, instead of having to visit some website with the snowflake proxy js code on
23:25:47 <catalyst> ahf: oh cool
23:25:51 <teor> How will we test snowflake as we add changes to it?
23:25:54 <nickm> yeah; last thing I want is a tab that I'm never allowed to close :)
23:25:57 <ahf> i absolutely *love* the idea of a webextension
23:26:10 <ahf> the idea that everyone can contribute almost like a relay with a browser plugin makes me super happy
23:26:23 <nickm> teor: good question.  ahf: do you know what the state of the snowflake tests is now?
23:26:23 <antonela> i think a webextension makes more sense as a one time effort
23:26:47 <ahf> nickm, teor: i don't, no, that is not something i've had time to look at
23:26:58 <ahf> arlo/dcf would be good to ask there
23:27:21 <ahf> antonela: yep, i think it's mostly having a neat UI that can use some of the info from the browser such as "am i roaming" / "am i on fast network" and then a way to configure it
23:27:23 <nickm> ok.  The engineers who worked on it are all smart responsible people, so I think there are probably going to be tests that we can work with
23:27:25 <teor> I think we need a full tor integration test, which means we need chutney or something similar. It's not enough to just have partial integration tests.
23:27:49 <ahf> teor: good points, that we don't have on our s19 roadmap right now
23:27:51 <nickm> I agree that one of the first things we should do is to assess the state of testing
23:28:00 <nickm> tesching chutney about PTs would be handy
23:28:06 <arma1> looking at testing early does sound smart.
23:28:15 <nickm> *teaching
23:28:24 <arma1> (following on the "first write the whole set of tests, and then fill in everything so that the tests work")
23:28:27 <ahf> and that might also sound like something that could fit well into our december plans which still have a lot of s8 too for some of us
23:28:28 <teor> Indeed. And I think we should do it as part of s19, otherwise we never will.
23:28:40 <ahf> teor: yeah, that is very plausible
23:28:49 <gaba> do any of you know how much time that could take?
23:29:02 <teor> Well, I could spend some quality time with chutney in December, and do the s8 bootstrap stuff, and the s19 PT stuff.
23:29:09 <antonela> ahf: i can work on that UI - do you have the headless ticket close?
23:29:18 <ahf> antonela: 2 sec
23:29:23 <gaba> teor: let;s chat about that. it may work fine
23:29:45 <nickm> gaba: so, integration tests in general is very open-ended.  But teor could probably estimate the time for making chutney handle PTs and/or snowflake
23:29:51 <teor> Can a headless snowflake run from the command-line
23:29:55 <ahf> #23888 is the webextension one
23:30:00 <ahf> teor: yeah, i think that is the idea
23:30:07 <gaba> ok
23:30:08 <antonela> thx - cli too is cool
23:30:31 <ahf> i think the headless one is called go-proxy, and the browser extension has no name yet
23:30:53 <arma1> cupcake was the browser extension to do this for flashproxy. in theory it could be extended to be snowflakes too.
23:30:54 <ahf> https://github.com/keroserene/snowflake/tree/master/proxy-go
23:30:59 <teor> gaba: if I do chutney travis tests, s8 bootstrap, and s19 PTs, it's about a week. A few days for each.
23:31:19 <arma1> https://github.com/glamrock/cupcake/issues/24
23:31:25 <teor> Doing the travis tests makes the whole thing faster, because I don't have to test every combination
23:31:27 <gaba> ok. would that means to let privcount on a side for a little bit, right?
23:31:31 <antonela> should we move forward with the headless/extension version? or do we want to have the js web client thing first?
23:31:49 <nickm> gaba, teor: also we should prioritize getting s8 bootstrap 100% done IMO
23:32:00 <gaba> yes, that is the priority for sure
23:32:04 <ahf> antonela: i think the js web thing is already there and is working right now?
23:32:05 <nickm> The temptation to do other stuff will be real
23:32:27 <ahf> yeah, we need to balance it here for december :-/
23:32:38 <teor> gaba: yes, but I will need the chutney travis changes to test PrivCount as well, and the s8 bootstrap and PT changes will also help with PrivCount
23:32:45 <gaba> ok
23:32:54 <nickm> I have another silly question to ask.  Is there anything blocking snowflake deployment that is _not_ on our deliverable list?
23:33:05 <teor> (chutney can launch PrivCount the same way it launches a PT)
23:33:28 <ahf> nickm: i think the test point that came up was not on our list of deliverables for s19
23:33:33 <arma1> nickm: url for deliverable list?
23:33:40 <teor> nickm: what is the current state of snowflake fingerprintability?
23:33:47 <gaba> we are looking at the roadmap and the s19 deliverables
23:33:57 <nickm> gaba: could you link to those for people?
23:34:00 <gaba> https://docs.google.com/spreadsheets/d/1Ufrun1khEo5Cwd6OwngERn829wU3W3eskdrriaYfUBQ/edit#gid=856122210
23:34:01 <nickm> teor: I don't know.
23:34:04 <teor> There is WebRTC fingerprintability here: https://trac.torproject.org/projects/tor/wiki/doc/Snowflake/Fingerprinting
23:34:05 <arma1> teor: snowflake fingerprintability situation is not good. it used the webrtc data channel, which nobody else uses.
23:34:12 <arma1> s/used/uses/
23:34:12 <teor> But the transport itself might be fingerprintable
23:34:19 <ahf> teor: there is some info on that on the snowflake trac page. one task could be to look at if the current chrome / firefox webrtc implementation matches that that is being used by go-webrtc right now
23:34:26 <gaba> that is the roadmap for the network team, (roadmap sheet)
23:34:29 <ahf> the go-webrtc lib uses the chrome C++ implementation i believe
23:34:56 <teor> Has anyone done a full privacy review?
23:35:08 <gaba> arma1: there is a deliverables tab in that document BUT I think what we do about snowflake is flexible for s19, right?
23:35:10 <teor> For example, nickm's question about the snowflake proxies learning the client's IP address
23:35:22 <ahf> i don't know the answer to that
23:35:47 <arma1> teor: if we want snowflake to survive the china arms race, we're going to need somebody on-hand to do tweaking to get around blocking, plus also plan the longer term roadmap of making it more like other users of webrtc
23:35:49 <ahf> yeah, the current tasks in the network team s19 roadmap is whatever we had on the postits in mexico i think?
23:36:17 <gaba> yes, and is also starting some work that will go into the anticensorship team plate
23:36:45 <teor> arma1: tweaking is good, but "enumerate all the clients" and "enumerate all the proxies" are design issues
23:37:38 <teor> we may need a guard design here
23:37:58 <arma1> teor: "spec for facilitator" and "improve robustness of facilitator" look like they're on-topic for that concern
23:38:10 <ahf> yeah
23:38:26 <arma1> and yes, the snowflakes can learn about some clients, just like current bridges can learn about some users
23:38:30 <teor> yeah, that should be handled by the broker, because it's too late after the broker has leaked your info
23:38:41 <teor> but can they learn about *all* clients?
23:38:49 <arma1> it depends how the broker behaves.
23:39:04 <arma1> there are a bunch of design choices around how bridgedb behaves, and the broker faces many of the same choices.
23:39:32 <arma1> this is why i described the broker as snowflake's bridgedb
23:39:35 <teor> I honestly think that we could easily forget to look at enumeration in "spec for facilitator" and "improve robustness of facilitator"
23:39:57 <ahf> we can add additional tasks
23:40:02 <nickm> yeah, we should.
23:40:04 <ahf> i don't think any of this is gonna be set in stone
23:40:12 <ahf> i think this might be the most open tasks we have on our roadmap
23:40:24 <ahf> we can move them around, add things, maybe not delete things
23:40:41 <nickm> so, here's my question that has probably been answered before...
23:40:51 <nickm> what has blocked snowflake roll-out up to this point?
23:40:56 <teor> Do we need a pipeline of replacement servers so we can act quickly when one is blocked?
23:41:13 <arma1> nickm: the main issue i think is that it doesn't build on windows, so it isn't in tor browser.
23:41:25 <nickm> teor: that would be smart.
23:41:31 <ahf> huh, ok, i can look at that in december for sure
23:41:37 <ahf> i'm starting to get used to windows by now
23:41:58 <arma1> nickm: the secondary issue in the past was that the broker was super naive and gave out snowflakes inefficiently and then there were no snowflakes offered to new users
23:42:01 <ahf> i think it just didn't build reproducibly on windows?
23:42:25 <arma1> ahf: i'm not sure. it doesn't build in a way that tor browser finds useful. :)
23:42:39 <ahf> ok, i can chat with GeKo about that i think
23:42:45 <catalyst> hm, how many web pages offered the snowflake proxy js?
23:42:56 <ahf> i've put my name on the windows task on our roadmap now
23:42:58 <antonela> arma1 is there where the web extension will improve snowflake proxy acquisition?
23:42:59 <arma1> catalyst: very few. so there are very few snowflakes currently.
23:43:02 <ahf> catalyst: probably not many
23:43:34 <catalyst> (gaba says she got disconnected and is trying to get back in)
23:43:36 <arma1> i think we can get a bunch of snowflakes pretty quickly just by tweeting or something. it won't be the long term plan but it will get us 'enough' to start
23:43:36 <nickm> arma1: can a snowflake only help one user at a time?
23:44:08 <ahf> i think it can handle more than one user at a time
23:44:12 <ahf> i'm almost sure about that
23:44:14 <nickm> in that case, how do we "run out" of snowflakes to offer to new users?
23:44:17 <ahf> like a relay can
23:44:18 <arma1> nickm: in principle no, but i see this ticket called #25601 that makes me nervous :)
23:44:18 <gaba> thanks catalyst. I'm back :) (on a driving car between mountains now...)
23:44:21 <ahf> but it can run out of bw
23:44:29 <nickm> yikes
23:44:42 <arma1> nickm: we run out because the broker has a simple algorithm like "give out each snowflake three times and then don't give it out for a while"
23:44:47 <nickm> ahf: see #25601 above?
23:44:48 <boklm> #25483 is the ticket for building snowflake on windows
23:44:53 <ahf> yeah, looking
23:45:22 <boklm> s/on/for/
23:45:26 <teor> For people with spare mobile devices, can we create an app or background process that snowflakes over wifi?
23:45:27 <nickm> okay.  Making the broker smarter seems do-able.   Making a non-multiplexing proxy multiplex seems harder.
23:45:52 <arma1> teor: yes and in fact nathan is excited to make it part of orbot, so when your device is sitting next to your bed, plugged in, while you sleep, you're helping people
23:46:08 <nickm> Also FWIW, WebRTC is _huge_.  We are not going to audit an entire webrtc implementation unless I'm deeply mistaken.
23:46:09 <ahf> boklm: yep, that is the one we have in our roadmap too
23:46:21 <ahf> ok, the #25601 situation is not so good
23:46:22 <teor> and for those of us with iOS?
23:46:45 <teor> I guess it's enough to have proxy-go on android
23:46:48 <arma1> teor: no idea, but should be doable.
23:47:35 <arma1> ("a simple matter of programming") s/programming/overcoming apple's monopolistic practices/
23:47:38 <nickm> So IMO within S19 we should prioritize stuff that we know we must do.  That's going to be fixing the blockers above, and the testing stuff we talked about
23:47:40 <teor> iOS has funny ideas about background tasks. It would have to be a fake "VPN", and Apple might block it from the app store because it's not actually being a VPN
23:48:20 <teor> nickm is right. Essentials first.
23:48:35 <arma1> nickm: that makes sense. another way of looking at it might be: what should the network team do, to make the new anti-censorship team hires be most effective once they start?
23:48:36 <gaba> +1
23:48:46 <ahf> yeah, i think doing apps is something we might hear benjamin from the guardian project about as well (for ios)
23:49:13 <ahf> it sounds a bit to me the windows thing is an issue, testing is an issue, and the #25601 is a pretty bad issue for deployment right now?
23:49:19 <teor> If the browser proxy can't multiplex, then it can't accidentally collect lots of client IP addresses
23:49:46 <teor> But it could deliberately find lots of clients by failing fast
23:49:55 * Samdney lurks ...
23:50:02 <nickm> teor: also, the failure mode of people not being able to get online seems bad.
23:50:19 <ahf> yeah..
23:50:23 <arma1> the broker currently has to guess, when it gives out a snowflake to somebody, whether that snowflake is actually still in use
23:50:24 <ahf> i think it is a scaling concern here
23:50:26 <teor> Indeed. We don't want to have to tweet every time snowflake gets low
23:50:29 <nickm> arma1: is there a ticket for the problem with the broker handing out snowflakes in a silly way?
23:51:22 <arma1> nickm: hunting
23:51:52 <arma1> there's #25681 which i guess has it implicitly
23:52:10 <arma1> but no, i think there is no simpler "just actually make it not dumb" ticket
23:52:17 <nickm> ok
23:52:40 <arma1> also the network team roadmap has a "spec for facilitator" line but i think there's no ticket for it yet
23:52:52 <arma1> imo the spec comes first, because "what does it do now" is a good step zero before making it smarter
23:52:59 <nickm> +1
23:53:00 * gaba was just looking for the spec ticket but no luck
23:53:16 <nickm> arma1: in answer to your early "what should the network team to do make the new anti-censorship team hires effective", I think the most helpful thing we'll do will be engaging with the code in the first place.
23:53:28 <arma1> yep
23:53:43 <nickm> That way the anticensorship folks will find a crew of people who sort of know the basics of what they're supposed to be working on
23:53:56 <arma1> speaking of future blockers, there's also #21314 -- at least currently, when my tor goes quiet/dormant, my snowflake keeps on sending traffic
23:54:14 <nickm> oh, yeah, that will matter.
23:54:39 <arma1> it's tied together with broader PT bugs, like #21967
23:54:50 <ahf> yeah, i think the part about being able to work with the new hires with a smooth handover is important
23:54:56 <teor> When is the s8 deadline?  December 31 2018?
23:54:58 <arma1> like, if i configure my tor to not longer use bridges or PTs, the PT sticks around
23:55:00 <ahf> teor: yep
23:55:11 <nickm> well, killing the PT is one part.  But PTs should generally try to be quiet when they aren't used
23:55:18 <nickm> so that's another part
23:55:24 <arma1> yep
23:55:40 <nickm> ahf, teor: Yup, that's the deadline, but if we can declare it finished earlier than that, it will be much better
23:56:05 <nickm> I'd rather minimize the amount of last-minute scrambling if I can
23:56:22 <teor> sure, we should aim for a few days before tor shutdown then
23:56:38 <nickm> yeah
23:57:24 <nickm> who on the network-team has actually used Go or JS for anything nontrivial before?
23:57:50 <nickm> (I haven't, though I've read a bunch and done some tiny things)
23:57:55 <teor> I have read a lot of Go and JS, and written a little bit of each
23:57:59 <ahf> i've done both go and some js before, mostly on the C++ side of javascriptcore in webkit
23:58:23 * Samdney ,too. although she isn't on network-team :)
23:58:41 * catalyst has dug around a bit in the snowflake proxy js, but is not a js expert by any stretch
23:59:01 <teor> https://exercism.io seems like a good site for programming language learning
23:59:18 <ahf> i have some go code still running at my old job which they don't maintain and don't complain about i hear, i think that might be the best go i've done :-P
23:59:26 <ahf> and that has been ~2 years soon since i left them
00:00:00 <teor> Is the snowflake proxy still written in CoffeeScript?
00:00:01 <nickm> ok. we are at the one-hour mark.  What else should we figure out here tonight?
00:00:05 <ahf> so, we have reached an hour now. i plan on going over the backlog and maybe create some tickets for some tasks we have talked about here, put them into our roadmap sheet
00:00:29 <ahf> and then at next network team meeting i hope we can maybe get some names on some of the important tasks we have identified here?
00:00:38 <nickm> yes, or maybe the one after.
00:00:47 <nickm> (I won't be able to make the next meeting, due to mozilla thing)
00:00:53 <ahf> ahhh! right, next meeting then
00:00:57 <ahf> gaba: does that sound OK with you?
00:01:06 <antonela> i can work on the webextension UI on December cc pili gaba
00:01:41 <arma1> antonela: do you know griffin? you might try to connect with him, since cupcake might be the closest path to having a working extension
00:02:00 <ahf> teor: i think so, yep, it gets compiled down to JS
00:02:04 <antonela> yes, oh cool, will ping him
00:02:21 <antonela> we have been talking via twitter dms, is he on irc?
00:02:27 <arma1> antonela: https://github.com/glamrock/cupcake/issues/24
00:02:46 <nickm> antonela: I dunno; ask him?
00:02:56 <arma1> antonela: he is sometimes 'saint' on irc but i have not seen him lately
00:03:02 <antonela> oki, will do
00:03:13 <arma1> Nickname last seen: Wed 14 Dec 2016 23:29:41 +0000
00:03:39 <gaba> sorry i got disconnected again (just reading back)
00:03:42 <ahf> ok, i'm gonna end the meeting log thing and go away from my computer for a bit. i'll do the things i wrote above
00:03:47 <ahf> and thanks all for coming by o/
00:03:52 <nickm> keen.  I think we made a good start
00:03:55 <ahf> #stopmeeting
00:03:57 <ahf> #endmeeting