I2P dev meeting, November 25, 2014 @ 20:00 UTC

Quick recap

  • Present:

dg, eche|on, EinMByte, JekabsR, kytv, orignal, psi, str4d, zzz,

IRC 完整日志

20:04:39  <str4d> Yo
20:04:44  <str4d> It's meeting time
20:06:47  <str4d> zzz, psi, kytv, Meeh, dg
20:07:30  <psi> it is?
20:07:39  <psi> ah tuesday
20:09:03  <zzz> present
20:09:48  <orignal> meeting?
20:10:11  <str4d> orignal: discussing Java I2P's todo list
20:10:35  <str4d> While we wait for others to show up: http://trac.i2p2.i2p/wiki/Roadmaps/1.0
20:10:41  <kytv> Present as well, though I'm usually useless when it comes to these things.
20:11:37  <str4d> I have adjusted the Gantt chart on the page above (that I set up for the 0.9.13-0.9.16 dev cycle) to show what I think we did.
20:13:30  <zzz> interesting
20:14:06  <zzz> multiple dests per tunnel <-- hasn't happened
20:14:22  <str4d> Hasn't? Okay, my bad.
20:14:27  <zzz> findbugs pass <-- has happened, but can always do it again
20:14:56  <str4d> Multi-sessions per I2CP - that hasn't happened either *derp*
20:14:56  * str4d fixes
20:15:48  <zzz> wow, we had a good year (imho)
20:16:38  <eche|on> yes, we had
20:17:14  <str4d> zzz: yeah, I called it part of the audit prep specifically, but you are right.
20:17:39  <zzz> investigate new DH <---- I would say only half done, w.r.t NTCP2 anyway
20:20:26  <str4d> Gantt doesn't easily show half-done :P
20:20:34  <str4d> Reload page, fixes
20:21:36  <str4d> Okay, so that is what we got done last cycle.
20:21:36  <zzz> not done then
20:23:45  <str4d> The purpose of this meeting is to start planning what is to be done next cycle.
20:23:46  <zzz> I would like to reiterate that a 3-5 release planning cycle seems to be very helpful in focusing our minds and our resources
20:23:47  <str4d> (When I update the Gantt chart, I will leave the half-done ones there and push them forward)
20:23:47  <str4d> At the previous meeting I asked attendees to come up with a few points each of things they want to see done on I2P, and around I2P
20:23:47  <str4d> Please can we paste those now?
20:24:21  <str4d> +1
20:24:36  <str4d> And now we have evidence for it!
20:26:15  <zzz> without getting into what's more important than what, I think almost everything that's shown and unfinished on the gantt chart is still important
20:27:01  <str4d> I agree.
20:27:07  <str4d> I still want to see what ideas people came up with over the last week, if any.
20:27:45  <str4d> Here's mine: http://pastethis.i2p/show/jF2RkHwrIPkCb0yOpI7l/
20:27:46  <iRelay> Title: Paste #jF2RkHwrIPkCb0yOpI7l | LodgeIt! (at pastethis.i2p)
20:28:07  <eche|on> I am out of options, I do see to get I2P out, with the help of bote android, i2p messenger is a option, a XMPP server, and syndie. Sorry, I still see syndie important.
20:28:27  <str4d> eche|on: great, thanks!
20:28:43  <str4d> Keep 'em coming :)
20:28:53  <eche|on> and with the android app there come restricted routes
20:28:54  <zzz> my list of new things: solving the red hat ECDSA problem, migrating to EdDSA, Jetty 9 / Java 7, expand the Vuze userbase, and more marketing / outreach / partnerships / embedding
20:29:36  <str4d> For logging perpetuity, I will write my ideas here too:
20:30:11  <str4d> Todo in I2P: Routerconsole UX analysis and redesign; Take ideas from Tor's HS 2.0 design and apply to I2P Destinations; Bandwidth scheduling. Todo around I2P: Website theme improvements; Implement I2P-Bote fetching relays; Research
20:30:23  <zzz> another one: orchid: fix it or kill it
20:30:32  <str4d> +100
20:31:13  <kytv> WRT the RedHat/Gentoo ECDSDA problem, maybe we could/should display a message in the sidebar (or logs) with a download link. Or maybe ask the user if 'we' should download it into ./lib
20:31:35  <zzz> another one: test improvements, test hardware, windows testing
20:31:58  <str4d> kytv: nice ideas (but discussing them can wait for another meeting :)
20:32:03  <zzz> another one: spend more money
20:32:36  <zzz> another one: China
20:32:58  <str4d> Between these ideas and the not-completed list on the page above, we have a good pool of potential projects.
20:33:34  <str4d> My goal is to get these projects tidied up, formalized and published on the website's todo page
20:34:11  <str4d> Having poked around other projects' todo pages, this is the format I am proposing:
20:34:11  <str4d> http://pastethis.i2p/show/nvexU3ZvSFOI6L5DrrqM/
20:34:12  <iRelay> Title: Paste #nvexU3ZvSFOI6L5DrrqM | LodgeIt! (at pastethis.i2p)
20:34:54  <eche|on> nice idea
20:35:10  <kytv> Ditto on Orchid
20:35:10  <kytv> My main "TODO around I2P" is with regards to testing. Not automated testing with software, per se, but any of our services going live without any sort of testing...just [poof], "it's live...dunno if it works though."
20:35:12  <kytv> In I2P: Making the Installer install to the user directory in Windows to avoid any sort of permissions problems. It should be easy, but I don't know how.
20:35:16  <kytv> Chrome did that (maybe still does it?)
20:35:41  <str4d> My ideal end result: users can go to the todo page and find a list of all the ideas we have for projects in and around I2P.
20:36:11  <zzz> another one: GSoC
20:36:14  <str4d> There will be a tag cloud up the top that they can click on to filter projects that require certain skils
20:36:17  <str4d> skills
20:36:21  <zzz> another one: summertime meetup
20:37:54  <zzz> another one: GNS investigation 2nd pass?
20:38:28  <str4d> mmm
20:38:54  <zzz> or maybe, just another discussion w/ those guys will do
20:39:09  <str4d> Right now, I am going to cull from the Gantt the tasks we have completed.
20:39:27  <zzz> can you save it and start a new one?
20:39:29  <str4d> zzz: which of the bottom few have been completed (SSU replay detection etc.)?
20:39:38  <str4d> Sure, I can.
20:39:49  <zzz> it's kinda nice to show that we actually accomplish things
20:40:19  <eche|on> zzz: most of the stuff was done by you IMHO
20:40:35  <EinMByte> id I miss the meeting?
20:40:37  <zzz> I think I've reported everything that was on the wrong side of completed or not
20:42:39  <str4d> New chart up
20:43:55  <str4d> zzz: which of the three down the bottom should be pushed forward? I think client locking is still an issue?
20:43:59  <zzz> I'd like to see much more planning and focus on the non-coding things in the next few months. Far too many things are either quite disorganized or not happening in anything approaching a disciplined or steady pace
20:44:09  <str4d> (client tunnel locking)
20:44:18  <str4d> zzz: I agree.
20:44:34  <str4d> This will IMHO be helped by working on the todo page.
20:44:56  <str4d> If we can explain the non-coding projects in a way that newcomers can understand and do, it also helps us.
20:44:59  <zzz> not 100% sure atm what that client locking item is, but i think it's still unfinished
20:45:08  <str4d> (Likewise for coding projects)
20:45:32  <zzz> yup
20:45:53  * str4d pushes streaming improvements forward too
20:46:03  <str4d> Can I cut SSU session replay detection then?
20:46:04  <dg> Do you mean the duplicate issues?
20:46:18  <dg> The way we'd get tunnels that don't unregister from I2PTunnel, and won't allow new ones? That sort of thing?
20:46:30  <zzz> str4d, I'll have to get back to you re: SSU replay, not sure atm
20:46:45  <dg> I'd like to see less tunnel death rather than throughput
20:46:59  <str4d> dg: that might be it. There is also the separate issue of the I2PTunnel startup locking the UI
20:47:29  <zzz> put 'tunnel death' on there as a new item, why not
20:48:01  <dg> str4d: Forgot about that!
20:48:03  <str4d> k
20:48:39  <zzz> I think the locking thing I have some unchecked in code for, been dragging along for 18 months or so, but still not right
20:48:40  <str4d> Next: look through the ideas above. Which ones should go on *our* 6-month sheet (ie. which should I add to Gantt)?
20:50:16  <psi> EinMByte: meeting in progress
20:50:21  <psi> (no)
20:51:51  <zzz> I suggest everything go on there for now, then we later talk about priorities, or let the gantt dependencies tell us what to do next?
20:52:52  <str4d> mmk
20:53:04  * str4d is pulling out the list from above and tidying it up now
20:53:08  <EinMByte> psi: oh great.
20:54:08  <psi> potential item: benchmark tunnel throughput and message drop rates
20:54:26  <str4d> EinMByte: do you have any ideas for our todo list?
20:55:15  <EinMByte> NTCP2, possibly. Although it would be long term
20:56:39  <str4d> EinMByte: for reference: http://trac.i2p2.i2p/wiki/Roadmaps/1.0
20:56:53  <EinMByte> thanks
20:57:04  <EinMByte> (was about to ask)
21:00:23  <str4d> Here is the list of everyone's ideas:
21:00:24  <str4d> http://pastethis.i2p/show/K0fGRb2708ADbCTZ9u9K/
21:00:25  <iRelay> Title: Paste #K0fGRb2708ADbCTZ9u9K | LodgeIt! (at pastethis.i2p)
21:01:01  <str4d> Nearly all of these can be turned into projects for the website todo page.
21:01:36  <str4d> Next discussion topic: which of these (and the ones on the Gantt currently) are more important for us to do in the next six months?
21:02:48  <psi> restricted routes is probably the most important item IMO
21:02:50  <EinMByte> with respect to syndie, maybe: I was working on this plugin - no time now though). This might be one of the things that can (?) bring more attention to syndie.
21:03:20  <dg> str4d: Tunnel death is absent and I feel that's quite important
21:03:37  <EinMByte> If anyone is interested in doing firefox / icedove plugin development: you know what to do
21:03:37  <str4d> dg: it's there (tunnel thread locking)
21:03:41  <str4d> I thought that's what it was
21:03:49  <dg> oh, sorry str4d, I meant when connections are abruptly terminated
21:03:54  <dg> my bad
21:04:04  <str4d> Ah, k
21:04:55  <EinMByte> psi: I agree restricted routes are important. But I also think we should realize that it will take quite some time to implement
21:05:21  <EinMByte> (not sure how much of the design / concept has been done)
21:05:35  <dg> In I2P: restricted routes, RedHat's ECDSA issues, Tor's HS 2.0, then the rest. Around I2P: Vuze userbase, GSoC, research, benchmark, then the rest.
21:06:04  <dg> I agree with EinMByte.. the router console redesign is important but that could take an indeterminate amount of time.
21:07:15  <EinMByte> str4d: one more thing, possibly. I know some reasearchers who have developed a new concept for a DWSE (distributed web search engine), they might be interested in developing this as an I2P application
21:07:42  <str4d> EinMByte: nice!
21:07:49  <EinMByte> Since most DWSEs right now don't really work well, it would be very interesting to have this IMHO
21:08:01  <zzz> no, by 'tunnel death' I meant 3-minute tunnel breakage, the Vuze guy's datagram test, etc. Distinct from local i2ptunnel locking issues.
21:08:07  <EinMByte> It's also something I would consider implementing
21:08:20  <dg> I wasn't thinking of precisely 3-minute but that was included.
21:08:34  <EinMByte> (with help, hopefully)
21:09:03  <str4d> k, reload Gantt page
21:10:34  <EinMByte> str4d: anyway don't count on this too much, it depends on whether I2P users are actually interested in something like this.
21:11:14  <EinMByte> Also, I'm not sure about the GNS stuff. In any case it shouldn't have a high priority.
21:11:56  <str4d> Updated new ideas paste: http://pastethis.i2p/show/1qxHbkWjD27N7SdzNJZL/
21:11:57  <iRelay> Title: Paste #1qxHbkWjD27N7SdzNJZL | LodgeIt! (at pastethis.i2p)
21:12:35  <zzz> i'd say 4 broad categories are the highest importance: 1) near-term crypto migration continuing (addressbook, muiltidest, etc) 2) longer-term crypto planning/research (DH, LS2, NTCP2) 3) all things testing 4) all things non-coding
21:13:48  <EinMByte> zzz: is that in order of importance?
21:14:05  <str4d> ECDSA issues fall into the first category; Tor HS 2.0 falls into the second category.
21:14:21  <zzz> no. roughly equal importance
21:14:44  <str4d> So the only item not represented in those categories is restricted routes
21:15:28  <jenkins@kyirc> Starting build #556 for job i2pd (previous build: SUCCESS)
21:15:30  <jenkins@kyirc> Project i2pd build #556: SUCCESS in 8.2 sec: http://jenkins.killyourtv.i2p/job/i2pd/556/
21:15:31  <jenkins@kyirc> * orignal: eliminated NTCPServerConnection
21:15:32  <jenkins@kyirc> * orignal: moved NTCP client code to Transports
21:16:34  <EinMByte> maybe NTCP2 is not *that* important
21:16:50  <zzz> and the reason I grouped them like that and say equal priority is that it's probably 4 separate groups of people for those 4 categories that could each make progress
21:17:08  <EinMByte> or, at least before we can start propertly on the NTCP2 we need to do a lot of research, also answer a few very important questions
21:17:33  <jenkins@kyirc> Project i2pd (Linux x86) build #33: SUCCESS in 1 min 47 sec: http://jenkins.killyourtv.i2p/job/i2pd%20(Linux%20x86)/33/
21:17:44  <EinMByte> zzz: indeed
21:17:51  <JekabsR> it is interesting that i2p network tends to bring all fast routers together
21:17:58  <jenkins@kyirc> Starting build #33 for job i2pd (Linux x64)
21:18:03  <zzz> right. "NTCP2" is just shorthand for a bunch of stuff that may or may not actually result in something called "NTCP2"
21:18:34  <JekabsR> and they do not prefer slow routers
21:18:40  <EinMByte> Yes. In any case if we change the transport layers it's extremely important not to make mistakes, as that would probably break I2P entirely.
21:19:19  <psi> JekabsR: slower routers are still used just not as much
21:19:43  <jenkins@kyirc> Project i2pd (Linux x64) build #33: SUCCESS in 1 min 52 sec: http://jenkins.killyourtv.i2p/job/i2pd%20(Linux%20x64)/33/
21:20:05  <EinMByte> zzz: if 2 is "research", then you are right though
21:20:33  <EinMByte> it can be done simultaneously
21:21:52  * str4d is reworking the Gantt into these four categories (plus an Other category)
21:22:12  <JekabsR> but there is a problem - client like destinations rarely get fast router connections
21:22:40  <eche|on> no?
21:22:46  <psi> JekabsR: not entirely sure if that is accurate
21:23:46  <zzz> str4d, did we forget Android, or is that a separate roadmap?
21:23:59  <str4d> zzz: we have forgotten it
21:24:01  <eche|on> JekabsR: hidden mode routers do have some issues, but other do get fast connections, as enough fast routers are available and do have free capacity
21:24:26  <str4d> Technically I2P Android falls into the "in I2P" category
21:24:35  <psi> oh another reasearch question: how much capacity does i2p actually have right now?
21:25:14  <zzz> maybe a 5th category for android makes more sense
21:25:46  <zzz> but I'm not hung up on categories. I just mentioned the 4 as a quick way to communicate what I think is important
21:25:54  <JekabsR> because they tend to create small number of really fast connections and large number of slow connections
21:26:11  <dg> [citation needed]
21:26:15  <JekabsR> my router started to drop slow tunnels
21:26:24  <str4d> zzz: I think it was a good idea
21:26:56  <str4d> Refresh Gantt page now
21:27:07  <eche|on> JekabsR: https://geti2p.net/_static/pdf/I2P-PET-CON-2009.1.pdf
21:30:12  <eche|on> JekabsR: tunnels are dropped only on end of tunnel lifetime and if own tunnels need the capacity.
21:30:29  <str4d> If you refresh http://trac.i2p2.i2p/wiki/Roadmaps/1.0 you will now see the headings, each with a six-month bar. This gives an indication of how much time there is to fit everything in.
21:32:43  <str4d> Now that we have some ideas for the next six months, we need to start planning times.
21:33:18  <str4d> And who is going to tackle what.
21:33:52  <JekabsR> my console frequently reports that it has too many incoming connections and tunnels are partially rejected. How i2p decides which one to reject?
21:34:08  <dg> 'too many incoming connections'?
21:34:21  <dg> JekabsR: a meeting is currently ongoing, you may want to wait until it's over
21:35:00  <str4d> I would also like some volunteers to help turn the list of ideas into a working projects page on the website todo
21:35:12  <JekabsR> NTCP connections: 425. Limit: 425. Timeout: 2 min.
21:35:30  <JekabsR> UDP connections: 1149. Limit: 1275. Timeout: 4 min.
21:36:14  <JekabsR> limits are hit
21:37:42  <JekabsR> router is using 80% of CPU power
21:38:23  <str4d> Anyone?
21:39:36  <kytv> JekabsR: 1) meeting underway, you may want to wait; 2) look at
21:41:16  <JekabsR> kytv: will check it out
21:41:44  <zzz> str4d, i think you lost everybody after an hour 45. Maybe declare victory for now and we'll make more progress at another time?
21:41:45  <str4d> Let's try some more specific questions.
21:41:52  <str4d> Or that./
21:41:55  <JekabsR> 330,0 / 342,4 KBps my current load
21:42:06  <str4d> Yah, we have definitely made good progress.
21:42:30  <JekabsR> and torrent uploads at 2 - 5kb speed :(
21:44:17  <str4d> Thanks for the discussions, everyone!
21:44:20  * str4d warms up the baffer
21:44:20  * str4d ***bafs the meeting closed