13:59:58 <karsten> #startmeeting
13:59:58 <MeetBot> Meeting started Thu Sep 29 13:59:58 2016 UTC.  The chair is karsten. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:59:58 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:00:02 <karsten> hello!
14:00:06 <iwakeh> hi :-)
14:00:10 <karsten> hey :)
14:00:12 <mnpkt> hi
14:00:17 <karsten> hi mnpkt
14:00:33 <karsten> https://pad.riseup.net/p/3M7VyrTVgjlF <- agenda pad
14:02:40 <karsten> alright, looks like we already have a few agenda items there. should we start?
14:02:46 <iwakeh> sure.
14:02:52 <mnpkt> sure
14:02:55 <karsten> * CollecTor misc., tasks to be completed Sep 30 (karsten)
14:03:19 <karsten> so, I think we worked on a few collector-related tickets in the past week or so.
14:03:34 <iwakeh> Isn't #19317 completed and can be merged?
14:03:47 <iwakeh> and, would be another finished task.
14:03:48 <karsten> we should try to finish some of them by the end of september, so that we can include them in the monthly report.
14:04:11 <karsten> it's completed and merged, there were just a few suggestions to be added later on.
14:04:18 <karsten> like 0b1111_1111.
14:04:29 <karsten> though I had problems with cobertura not understanding those literals.
14:04:41 <iwakeh> ok
14:04:46 <karsten> but those suggestions were referenced from another ticket, so it's probably safe to close that ticket.
14:05:06 <iwakeh> yes
14:05:35 <karsten> okay, I'll close it after the meeting, after looking once more.
14:05:49 <karsten> I also worked a bit on #19755 yesterday.
14:06:02 <iwakeh> to make sure:
14:06:10 <iwakeh> branch task-19755-2: latest 14 commits for review?
14:06:18 <karsten> heh, let me count them..
14:06:48 <karsten> yep. 14.
14:06:56 <karsten> the first is big, the others are much smaller.
14:07:03 <iwakeh> ok.
14:07:09 <karsten> and I think you saw a very similar version of that first commit earlier.
14:07:21 <karsten> basically, I cleaned that up to make it easier to review.
14:07:28 <karsten> and fixed more things.
14:07:33 <iwakeh> fine.
14:07:43 <iwakeh> doable in Sep.
14:07:51 <karsten> nice!
14:08:06 <karsten> then we have #20228 and #20234.
14:08:18 <iwakeh> right.
14:08:48 <iwakeh> protocol 0.9?
14:08:57 <karsten> quick idea: can we include a compact version of that text file in index.html?
14:09:08 <iwakeh> I'd rather not.
14:09:11 <iwakeh> It's
14:09:28 <iwakeh> the 99% are not really interested part.
14:10:02 <iwakeh> Or, have it all in html.
14:10:06 <iwakeh> ?
14:10:06 <karsten> well, I wonder if we can find a representation that makes it more interesting to the average user.
14:10:33 <karsten> I mean, we do have an informal version of that protocol on index.html.
14:10:34 <karsten> like:
14:10:57 <karsten> "The server descriptors in the descriptor archives contain one descriptor per file, whereas the recently published files contain all descriptors collected in an hour concatenated into a single file. "
14:11:27 <karsten> maybe we can find a representation for paths that is easily comprehensible and that contains many more details.
14:11:31 <iwakeh> That's the part explicitly excluded from the file structure protocol.
14:11:41 <iwakeh> ok.
14:12:06 <iwakeh> That would need more text I think.
14:12:10 <karsten> oh, yes.
14:12:19 <iwakeh> longer descriptions.
14:12:32 <iwakeh> The more technical protocol could be
14:12:42 <iwakeh> linked from html first.
14:12:57 <iwakeh> I mean , link the git repo document.
14:13:05 <iwakeh> If there are request
14:13:17 <iwakeh> or questions it could be added later?
14:13:18 <karsten> maybe we can find a notation with placeholders for "valid-after month", "published second", dash, compression type, etc.
14:13:37 <karsten> and put something in that notation on the html page.
14:13:48 <karsten> I don't yet know how exactly that would work. I haven't tried.
14:14:28 <iwakeh> as a first step proto 0.9 could be finished?
14:14:57 <karsten> and as second step we try to simply that and include it in the html?
14:15:45 <karsten> looks like we lost iwakeh..
14:16:08 <karsten> mnpkt: want to discuss your questions?
14:16:13 <karsten> * short questions about collector file parsing & path selection algorithms (if theres time) (mnpkt)
14:16:16 <mnpkt> sure
14:16:18 <mnpkt> thanks
14:16:54 <mnpkt> so i got a small Rscript to parse part of the consensus files from collector
14:17:12 <mnpkt> this helped a lot: http://jordan-wright.com/images/blog/how_tor_works/consensus.png
14:17:26 <mnpkt> is there something similar for the other files?
14:17:39 <karsten> well, there are libraries for the parsing.
14:17:43 <karsten> not for R though.
14:18:07 <karsten> but I'd think that other languages are better suited for parsing lots of descriptors anyway.
14:18:07 <mnpkt> just documents describing which variable means what?
14:18:16 <karsten> ah, no, APIs.
14:18:19 <mnpkt> that is probably true
14:18:21 <mnpkt> :)
14:18:24 <karsten> do you know java or python?
14:18:27 <karsten> or maybe go?
14:18:35 <mnpkt> a bit python but feel much more comfortable in R
14:19:00 <karsten> well, you'd only have to use python to turn descriptors into something that R can process more easily.
14:19:06 <karsten> and I think there are tutorials.
14:19:25 <karsten> https://stem.torproject.org/tutorials/mirror_mirror_on_the_wall.html
14:19:41 <mnpkt> thanks I will give that a try
14:20:04 <karsten> okay. and your second question was about path selection?
14:20:11 <mnpkt> yes
14:20:42 <mnpkt> so I looked at the specs and am unclear if it is possible clients select a non guard flagged relay as entry
14:21:03 <karsten> wb iwakeh
14:21:05 <iwakeh> back again
14:21:12 <mnpkt> since there are weigths for that in the consensus
14:21:19 <mnpkt> hi iwakeh
14:21:21 <karsten> hmmmm
14:21:29 <mnpkt> Wgm - Weight for non-flagged nodes in the guard Position
14:22:20 <mnpkt> and additionally if the self described bandwith of the relays is actually used as additional weigth in Guard selection
14:22:32 <mnpkt> found that here:
14:22:39 <mnpkt> path sprec 5.1 Guard selection algorithm 4.
14:22:45 <mnpkt> * CRN_NEED_CAPACITY: potentially suitable routers are weighted by
14:22:45 <mnpkt> their advertised bandwidth capacity.
14:22:50 <karsten> the bandwidth that's contained in the consensus is used. plus the Wxx weight.
14:22:52 <mnpkt> https://gitweb.torproject.org/torspec.git/tree/path-spec.txt
14:23:16 <karsten> I'm surprised that that weight is not 0.
14:23:24 <mnpkt> me 2
14:23:27 <karsten> I can't give you a clear answer now.
14:23:33 <mnpkt> ok
14:23:41 <karsten> you could look at the tor code.
14:23:47 <karsten> and see what clients do.
14:24:02 <karsten> or you could look at TorPS, which is a path simulator.
14:24:13 <mnpkt> ahh that sound promising
14:24:20 <karsten> or ask again in this channel when core tor devs are around.
14:24:29 <karsten> though they're likely busy this week with the meeting.
14:24:43 <karsten> ok.
14:24:56 <karsten> hope that helps. shall we go back to the earlier topic?
14:24:59 <mnpkt> ok thanks very much
14:25:01 <mnpkt> sure
14:25:05 <iwakeh> yes.
14:25:15 <karsten> 14:15:00 < karsten> and as second step we try to simply that and include it in the  html?
14:25:18 <karsten> 14:15:48 < karsten> looks like we lost iwakeh..
14:25:25 <karsten> simplify*
14:25:48 <iwakeh> ok, so we can finish proto 0.9 in sept?
14:26:20 <karsten> my main concern is that we're creating another document that we need to maintain.
14:26:31 <iwakeh> see comment:9 of #20234
14:26:38 <karsten> if we remain open to transforming it to something else, like the html, I'm all for it.
14:26:45 <iwakeh> oh, sure.
14:27:20 <karsten> yes, that comment makes sense to me.
14:27:30 <iwakeh> fine :-)
14:27:37 <karsten> I'll do another review then.
14:28:03 <iwakeh> after I add another version with the mentioned changes.
14:28:07 <iwakeh> in sept?
14:28:12 <karsten> oh.
14:28:20 <karsten> hopefully. :)
14:29:26 <iwakeh> we're in agenda point two, now.
14:29:33 <karsten> then we could try to resolve the question of file-by-published-time vs. file-by-downloaded-time.
14:29:50 <karsten> #20228
14:29:57 <iwakeh> now?
14:30:05 <karsten> before end of sep.
14:30:21 <karsten> and maybe send out the tor-dev@ notice tomorrow.
14:30:32 <iwakeh> well, ... we
14:30:45 <iwakeh> could make that two questions:
14:31:09 <iwakeh> 1. make the change to append votes into one doc
14:31:50 <iwakeh> and 2. how to group the descs into files.
14:31:53 <iwakeh> ?
14:32:08 <karsten> sure, those are separate questions.
14:32:19 <iwakeh> the initial vote grouping could be by download time just b/c of the reason that
14:32:48 <iwakeh> this is, currently, done with the other descs too.
14:33:47 <iwakeh> I still favor grouping by published-time.
14:34:06 <karsten> I think we have different use cases in mind.
14:34:23 <iwakeh> yes, just needs some more pondering over this.
14:34:34 <karsten> here's an issue with grouping by published time:
14:34:37 <karsten> (just came to mind)
14:34:45 <iwakeh> :-)
14:34:47 <karsten> imagine you receive a descriptor that was published 70 hours ago.
14:34:56 <karsten> would you take that out of recent/ 2 hours later?
14:35:08 <iwakeh> why not?
14:35:26 <iwakeh> it will be in the tar.
14:35:46 <karsten> yes, but the recent/ dir is for clients that want to stay updated without having to look at the tars.
14:35:51 <karsten> it's a different channel.
14:36:16 <iwakeh> yes, but won't clients be confused by aged descs?
14:36:20 <karsten> and the idea is that they can fail for 2+ days and still get all the descriptors they need when they come back.
14:36:43 <karsten> they shouldn't be.
14:36:56 <karsten> nothing guarantees that descriptors come in order.
14:37:06 <iwakeh> but they don't expect them either.
14:37:17 <karsten> clients? they shouldn't.
14:37:23 <karsten> not the clients I wrote.
14:37:25 <karsten> ;)
14:37:33 <iwakeh> ok :-)
14:37:34 <karsten> we *could* make that more explicit.
14:37:49 <karsten> anyway, happy to discuss more on trac.
14:37:51 <karsten> and move on to 2.
14:38:00 <iwakeh> sure, part is
14:38:16 <iwakeh> already answered with the tasks we addressed already.
14:38:19 <karsten> ok.
14:38:22 <iwakeh> #20236  up for review or asking for info/input?
14:38:36 <karsten> oh!
14:38:42 <iwakeh> (Didn't notice #20227 for that reason, i.e. that is was still 'new')
14:38:57 <karsten> argh, ok.
14:39:13 <karsten> there was no patch to review..
14:39:18 <karsten> just an idea to discuss.
14:39:28 <iwakeh> true, could have been needs-info
14:39:35 <karsten> it's also not urgent, it just came to mind as something that could be done quickly.
14:39:38 <karsten> right.
14:39:45 <iwakeh> I replied already.
14:40:11 <karsten> okay, sounds good.
14:40:21 <iwakeh> so this goes in sep?
14:40:26 <karsten> quick answer is that we probably don't want to prioritize finding somebody else to work on this.
14:40:35 <karsten> removing? yes.
14:40:51 <iwakeh> but is it important enough to
14:40:52 <karsten> part of the goal there was to prototype a new graphing engine.
14:41:06 <karsten> and this was the sample that the volunteer was working on.
14:41:07 <iwakeh> keep a note about this somewhere with lower priority?
14:41:25 <iwakeh> ah, ok, now I get the point.
14:41:31 <iwakeh> then just remove.
14:41:43 <karsten> yep. and remember locally. :)
14:41:50 <karsten> I have more ideas here... ;)
14:41:51 <iwakeh> on paper.
14:42:03 <karsten> heh, sort of.
14:42:31 <karsten> okay, I don't think that patch needs review.
14:42:35 <karsten> removing code.
14:42:38 <iwakeh> fine.
14:42:46 <karsten> just as a way to speed up things.
14:42:56 <karsten> realizing that end of september is near.
14:43:02 <iwakeh> yep.
14:43:13 <karsten> okay, what other questions?
14:43:26 <iwakeh> topic two is done.
14:43:30 <karsten> ok.
14:43:35 <karsten> * Tor Metrics usability analysis (karsten)
14:43:44 <karsten> I didn't hear back from UX folks.
14:43:44 <iwakeh> was it reviewed?
14:44:06 <karsten> but I wonder if we should give that more time and not publish early.
14:44:26 <iwakeh> depends on the way of publishing?
14:44:37 <karsten> right.
14:45:15 <karsten> well, now that I think about it, I'd say let's wait another week or two.
14:45:17 <iwakeh> what makes you reluctant publishing?
14:45:32 <iwakeh> yes, we have time to wait.
14:45:34 <karsten> that attention will be lower when publishing a revision.
14:45:45 <karsten> and maybe the revision will be much better with input from UX folks.
14:45:48 <iwakeh> that's true.
14:46:02 <karsten> okay, never mind the agenda item then.
14:46:05 <karsten> we'll wait.
14:46:26 <karsten> alright. we already discussed item 4.
14:46:32 <karsten> what else? :)
14:46:42 <iwakeh> hhmm, action items?
14:46:44 <iwakeh> :-)
14:46:54 <karsten> yeah, I collected them during the meeting.
14:46:59 <karsten> anything I missed?
14:47:11 <iwakeh> not that i'm aware of.
14:47:25 <karsten> okay, cool!
14:47:44 <karsten> so, talk more next week?
14:47:44 <iwakeh> back to work :-)
14:47:46 <karsten> hehe
14:47:48 <iwakeh> sure.
14:48:05 <karsten> great! thanks! :)
14:48:08 <karsten> #endmeeting