21:59:02 #startmeeting Simple Bandwidth Scanner (sbws) Meeting 21:59:02 Meeting started Thu Apr 19 21:59:02 2018 UTC. The chair is pastly. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:59:02 Useful Commands: #action #agreed #help #info #idea #link #topic. 21:59:07 Pad: https://pad.riseup.net/p/BenwGdgpz0uS 21:59:23 Hello people interested in sbws. 22:00:09 hi pastly 22:00:19 why sbws 22:00:33 not bandwidth scanner in general? 22:01:08 Ah. Is there non-sbws bw scanning stuff to talk about? 22:03:05 (Just want to briefly thank ln5 again for the server space to help make sbws a real thing) 22:03:50 teor4: are you able to make this meeting? 22:05:21 I am here 22:05:47 Well. I left some updates in the pad. Big things I did last week are mostly a painful logging library switch and starting a dirauth in the testnet. 22:06:43 juga helped me remember that someday soon I'll hopefully have time during the day to work on a peerflow-like thing, so maybe I should be making sure sbws is headed towards completion 22:07:22 Which is good, because I think it is nearly ready. 22:07:38 Nothing big off the top of my head needs implementing. 22:07:56 docs, tests, and user support are the primary things I want on my plate :) 22:08:20 anybody else want to mention some updates? 22:08:33 Regarding sbws or other things? 22:09:49 pastly: in pad 22:10:31 hmm 22:10:37 "once sbws repo is public, can we work on new releases publicly?" 22:10:40 Yes. 22:10:44 Good question 22:10:54 pastly: thanks for the answer 22:11:44 I'm thinking I could quickly throw the sbws docs on an onion service in the next ~day. Would that be helpful to anyone? 22:11:58 (and initially only share it privately) 22:11:59 sure 22:12:18 what about having them in rtfd if repo public next week? 22:12:57 As soon as the repo is public I plan on looking at putting them on readthedocs. 22:13:07 k, thx 22:13:10 I just don't want to have to give them my password or something. 22:13:16 I'm sure that's not required for a public repo 22:13:55 u'll need to give them access your gh via oauth 22:14:27 alrighty 22:15:41 While talking to a dirauth, they expressed concern about trusting people other than themself to run sbws servers. 22:16:23 And that they may not have a good enough machine handy to run a full helper themself. 22:16:58 So even if we can convince some relay ops to run sbws, I'm not sure many of the dirauths will want to use "random" helpers. 22:17:43 I see a few ways forward other than just ignoring this and hoping it works out okay. 22:18:10 1. completely switch fundamentals and use HTTP(S). Then instead of sbws servers we'd have web servers, potentially on CDNs. 22:19:06 2. Run big public-ish sbws servers that aren't near relays. Add encryption to the wire protocol so auth passwords aren't leaked. And don't require peopel to run sbws servers 22:19:24 And that's the end of my ideas. 22:20:16 You could ask the dirauth list which option they prefer 22:20:18 2. could still be close to helper relays 22:20:18 Anything sound significantly less bad than the others? 22:20:45 1 is a lot less effort to maintain in the long term 22:20:52 teor4: what's the list name? 22:21:41 see pm 22:21:48 ln5: unless I'm greatly mistaken, you run a dirauth. Any of these options sound not bad? Would you run a bwauth with any of these? 22:21:51 teor4: thanks 22:22:20 juga: yeah, they could. Could run some in the biggest data centers for tor relays 22:23:55 pastly: what does "a full helper" mean? a non-exit relay with no bw cap? 22:24:12 teor4: I really appreciate the input you've been giving on sbws tickets. Do you think network team involvement will pick up once sbws is open? 22:24:20 another advantage of 1 is that it can re-use the existing bandwidth servers 22:24:51 ln5: the sbws server + a relay that (ideally) is underutilized and capable of a lot of bw so it isn't a limiting factor in measurements 22:25:04 teor4: 22:25:12 pastly: you could ask isis or catalyst to be involved once the code is open 22:25:17 ops 22:25:24 they are assigned to the task on the roadmap 22:25:57 i don't see how this is so much different than the current situation where ppl either run their own bandwidth server (a web server) or use the one from the setup docs 22:26:28 or sorry, i see how the resources required are higher 22:26:36 yeah. crypto mainly 22:26:43 And no CDN option 22:26:53 but for the question of trusting someone to run one, i mean 22:27:30 i am running a dirauth but i might not be representative since i take bw data from someone else, whom i trust 22:27:58 Alright. Thanks 22:28:20 i'd be happy to try running sbws though, fwiw 22:28:47 * pastly wonders if we could convince Tor to run a few scattered sbws servers 22:29:08 (for some definition of "Tor" ...) 22:29:47 ln5: maybe you can be the first real dirauth to try it :) 22:30:42 Ok so I'll ask the dirauth list what they think regarding this 22:30:47 I think the scaling will help with some of the resource issues 22:30:47 teor4: any thoughts about the tasks? 22:30:47 Tor Project Inc doesn't run any parts of the tor network but there are other organisations who are pretty trusted that do 22:31:10 so if you don't have enough CPU, you can scan the network slower 22:31:49 and if you can't sustain high speeds due to CPU, you will scale all your results, but the order will still be correct 22:32:34 Unless $large_number relays all have essentially the same result since they can do more than you're measurement setup can measure 22:34:33 that's fine, they will still be scaled large 22:36:07 people can always stay on torflow 22:36:30 Hehe yeah. Can't be that bad if we're still using it :p 22:36:34 Is there anything else we should talk about? Any questions? Concerns? 22:37:20 Everyone know what they want to work on, whether its sbws-related or not? :p 22:38:16 pastly: maybe we can have some informal follow up around 10amUTC somewhere? 22:38:23 or on monday 22:38:38 juga: sure. 22:38:49 1000 utc is fine 22:38:59 just cause i'm toooo sleepy, and partly think missing teor4 22:39:45 I'm excited that we seem to be making big, real strides to replacing torflow 22:40:27 pastly: that was one of the ideas :) 22:40:38 it's also important to have a process that works for any new scanner 22:41:17 Yeah. 22:41:38 This might be useful for whatever I/we at NRL come up with next. 22:42:16 And I don't think I need to be taking up any more of y'alls time this morning/evening/whatever. 22:42:44 ok, thanks 22:42:54 Thank you all for coming. Thanks for your support. 22:43:04 thx pastly, sry for my sleepiness 22:43:17 Catch you all on the flippity floppity ;) 22:43:23 juga get some sleep :p 22:43:25 #endmeeting