14:05 < jrandom> 0) hi 14:05 < jrandom> 1) 0.3.2.3, 0.3.3, and the roadmap 14:05 < jrandom> 2) s/reliability/capacity/g 14:05 < jrandom> 3) website updates 14:05 < jrandom> 4) attacks and defenses 14:05 < jrandom> 5) ??? 14:05 < jrandom> 0) hi 14:05 * jrandom waves 14:05 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2004-July/000358.html 14:06 < jrandom> swingin right into 1) 0.3.2.3, 0.3.3, and the roadmap 14:07 < jrandom> (while y'all read ahead, i assume ;) 14:07 < jrandom> the 0.3.2.3 release is out there and seems to be doing well 14:07 < jrandom> what are the main pain points people are seeing? 14:08 < deer> no trouble at all 14:08 < deer> 4d uptime with no problems 14:08 < jrandom> hmm, word 14:08 < deer> for some irc doesnt seem too stable 14:08 < deer> like kaji getting kicked ever minute 14:08 < deer> but thats nothing new 14:09 < jrandom> yeah that happens to him on the freenode network too, so i'm not sure what to blame there 14:09 < deer> yeah 14:09 < deer> connelly had some bad downloads afaik 14:10 < deer> but you dont hear me complainin' 14:10 < jrandom> ah really? hmm, i think we found some of those were related to his lib, but i've experienced the occational failure on larger file transfers 14:10 < jrandom> especially while leeching books from alexandria 14:10 < jrandom> (well, not especially, but thats the only site i leech from) 14:11 < deer> :) 14:11 < jrandom> ok, well, my plan is that once the 0.3.3 release is out, my time will be focused on getting us to 0.4, along side any bugfixes people bring up 14:12 < jrandom> the 0.4 work that is left is largely simple web stuff (new router console w/ servlets, jetty integration, servlet to control the router, and a servlet to config the i2ptunnel instances) 14:13 < jrandom> perhaps some jsp/servlet folks can help out with some of that to get their feet wet with the code, though i've done plenty of that stuff before so impl won't be too tough 14:13 < jrandom> afaik hypercubus' installer is pretty much good to go 14:13 < jrandom> (though i threw some new work on him today ;) 14:13 < deer> featurecreep++ 14:14 < jrandom> keeps people on their toes :) 14:14 < jrandom> (but c'mon, everyone hates downloading all the jars seperately for upgrades) 14:14 < deer> yes, that is my biggest problem with upgrading 14:14 < deer> (though I use cvs) 14:14 < deer> but it would be if I didn't 14:15 < jrandom> heh 14:15 < mihi> jrandom: just tar all of them -> 1 download ;) 14:15 < jrandom> that'd be simple enough, and leave updgrade.sh/upgrade.bat == jar xf upgrade.jar 14:16 < jrandom> (after a wget-esque call) 14:16 < jrandom> well, i think hypercubus has the code to do all that stuff under control, so we can leave it up to him to do the Right Thing 14:17 < jrandom> anyway, yeah, as y'all may have noticed, our schedule isn't quite what it was before 14:17 < jrandom> the roadmap has been updated and eeeellloooonnnggaattteedd 14:18 < mihi> jjrraannddoomm:: cchheecckk yyoouurr dduupplleexx sswwiittcchh 14:18 < deer> hah 14:18 < jrandom> heh 14:18 * mihi made a mistake... who spots it first? 14:19 < jrandom> (\n\n) 14:19 < jrandom> but anyway 14:19 < mihi> okay, another one ;) 14:19 < duck> (no double spaces) 14:19 < mihi> duck++ 14:20 < jrandom> i do think the roadmap is pretty realistic at least through the 1.0 release now, though depending upon the user adoption and feedback we may reorder or drop one of 0.4.2 or 0.4.3 14:20 < jrandom> (and, of course, as always the roadmap is subject to change if more people get involved :) 14:21 < modulus> maybe one day I will, after I learn java, but i2p doesn't sound like a project for a novice. 14:21 < deer> yeah, it'll take longer :) 14:21 < deer> * duck expects some more slips along the road 14:21 < modulus> :-) 14:22 < deer> * duck can barely call it slips, look at the impressive table on http://www.i2p.net/redesign/announcements 14:22 < jrandom> slips may happen of course, but i think the milestones left are all pretty doable 14:22 < jrandom> yeah, thanks for showing that i have no life duck ;) 14:22 < deer> this is your life 14:22 < modulus> so, when's 1.0 out? :-) 14:22 < deer> be proud of it 14:23 < jrandom> modulus: while some parts of i2p are a bitch, there are a lot of pieces that can be tackled by a new developer pretty easily 14:23 < modulus> probably rather boring parts though, no? 14:24 < jrandom> naw, not at all. for example, whipping up a neat anonymous file transfer or chat app, a mini webserver, a mud, a chess app, whatever 14:24 < duck> (website updates) 14:24 < modulus> hmm, sounds cool. 14:24 < jrandom> (aka simple client apps that can be anonymous) 14:24 < jrandom> and of course web updates ;) 14:25 < modulus> what's this web updates deal? 14:25 < jrandom> our website needs work (see http://dev.i2p.net/pipermail/i2p/2004-July/000358.html or wait a few minutes for agenda item 3) 14:25 < cat-a-puss> Where does myi2p fit into all that? 14:25 < modulus> ah ah 14:26 < jrandom> cat-a-puss: http://www.i2p.net/redesign/myi2p :) 14:26 < modulus> methinks myi2p isn't a priority right now... 14:26 < jrandom> (i just wrote a brief page about it a few hours back) 14:27 < jrandom> as an aside, website updates are all posted to the i2pwww mailing list (http://dev.i2p.net/pipermail/i2pwww/2004-July/thread.html) 14:28 < modulus> hmm, i could write a global naming ap :-) 14:28 < jrandom> but i do still see the myi2p implementation (at least the base address book and blogging) being implemented for the 1.0 release 14:28 < jrandom> (per the roadmap, slated for november) 14:28 < jrandom> yes, you certainly could 14:28 < modulus> something simpler than DNS, with authentication and delegation of TLD's 14:28 < jrandom> it wouldnt be a bad thing to have either - a simple app that you could query a central name server would be nice 14:29 < modulus> yep 14:29 < jrandom> so, get coding :) 14:29 < modulus> I'll start tomorrow. beat me up if i'm on other things ;-) 14:29 < jrandom> hehe cool, shall do 14:29 < jrandom> ok, moving on to 2) s/reliability/capacity/g 14:29 < duck> small questio on the site: 14:29 < duck> oh wait 14:29 < duck> thats 3 14:29 < duck> sorry 14:29 < jrandom> sure, sup? 14:30 < jrandom> ah, 'k 14:30 < jrandom> there is going to be a fairly fundamental change to the peer profiling and selection code in the 0.3.3 release, as described in the email and http://www.i2p.net/redesign/how_peerselection 14:31 < jrandom> i've got it running on a pair of routers atm and it seems fairly well behaved (Speed: 25.18 (5 fast peers) Capacity: 17.50 (8 high capacity peers) Integration: 37.00 (2 well integrated peers)) 14:31 < jrandom> and no more negative values :) 14:31 < modulus> :) 14:32 < jrandom> i'm going to kick the tires a bit more, perhaps for another day or two, and then push 'er out as 0.3.3 14:32 < cat-a-puss> d 14:32 < cat-a-puss> 14:32 < cat-a-puss> oops 14:33 < duck> suggesting against updating cvs? 14:33 < cat-a-puss> to do dns look at a cache of http://www.levien.com/thesis/compact.pdf 14:33 < jrandom> nope, cvs is fairly stable atm 14:33 < jrandom> (but as always, be prepared to fall back if some nastiness hits) 14:35 < jrandom> looks cool cat-a-puss, thanks 14:35 < cat-a-puss> (I have a copy of the origional if anyone wants it) 14:36 < jrandom> the google cache kind of garbles the images a bit, so if you have the raw pdf that'd be great 14:36 < jrandom> anyway, we're sliding a bit off topic for the moment (but we can get back to this) 14:37 < jrandom> that's about it for the reliability/capacity switch, so moving on to 3) website updates 14:37 < jrandom> duck: you had something you wanted to bring up? 14:38 < jrandom> while duck prepares his notes, perhaps anyone has any ideas/suggestions/concerns wrt the items posted in the email? 14:39 < deer> the website looks good 14:39 < jrandom> yeah, i like the new nav and the site layout is quite clean 14:40 < deer> easier to find stuff 14:40 < cervantes> _much_ easier to find stuff 14:40 < duck> first of all I want to thank our user advocate protocol for becoming useful :) 14:40 < jrandom> heh 14:40 < duck> he had some good suggestions and he did just start 14:40 < cervantes> hip hip horray! 14:40 < jrandom> (hear hear!) 14:41 < duck> next I think that there is barely a reason not to put the redesign up for real 14:42 < jrandom> agreed - perhaps we can just mark the news/development/documentation as non page nav elements, drop the jvm and config tweaks for the moment, and get some basic content for the I2PTunnel page, i think we can deploy it 14:42 < jrandom> i just want it to go live with all links working (and all pages that arent working) 14:43 < jrandom> there will of course be further updates after it goes life ;) 14:43 < jrandom> er, live 14:44 < jrandom> as an aside, wilde has hooked up our 34sp account too, so we'll be able to migrate the site over there when necessary 14:44 < cervantes> coolio 14:44 < jrandom> thoughts duck? can the menu.php thingy handle non-page nav entries? 14:44 * cervantes checks his inbox for referal points 14:45 < jrandom> (or would it be too much effort to mod that in?) 14:45 < jrandom> hehe cervantes, that should be on the way 14:45 < cervantes> ;-) 14:45 < cervantes> ah the old "cheque's in the post" gambit 14:47 < duck> sorry; doing some other work in the meanwhile. 14:47 < duck> ok; yes possible to make it nav section title only 14:47 < jrandom> np, we can move on and come back to it later if you'd prefer 14:47 < jrandom> ok cool 14:47 < jrandom> (duck++) 14:48 < jrandom> ok, any other website related stuff? 14:48 < duck> with your suggestion it sounds ready for up. 14:48 < jrandom> if not, we can move on to 4) attacks and defenses 14:48 < duck> . 14:48 < jrandom> word 14:49 < jrandom> ok, i'm assuming y'all read the mailing list and have seen connelly's posts and the various replies 14:50 < cervantes> he's been busy :) 14:50 < cervantes> (almost as much as proto) 14:50 < Connelly> imo, the network looks sound to all except traffic analysis (sites with lots of traffic), and government connection-severing attacks, and for attackers taking over a large majority of the net 14:50 < jrandom> while i think we're in pretty good shape, i'm certain that there must be something (or things) we've missed, so please don't assume i2p does or will do what it says - challenge the assumptions and say why it sucks 14:50 < Connelly> the encryption pretty much screws over any non-aggressive attacks 14:51 < jrandom> that is the hope 14:51 < jrandom> plus with i2p 2.0 and 3.0 capabilities, defenses for attacks by govt scale adversaries will be possible 14:51 < Connelly> course in practice there will be security holes to patch 14:52 * jrandom still needs to write up some docs as to how the 3.0 delays will prevent segmentation attacks 14:52 < jrandom> certainly connelly 14:54 < jrandom> ok, if there's nothing more along those lines, i think thats all i've got 14:54 < jrandom> so 5) ??? 14:55 < jrandom> oh, as an aside, i plotted the bandwidth usage vs. # tunnels participated in graph for one of the simulations over a 4 day period 14:55 < jrandom> thats posted up @ http://dev.i2p.net/~jrandom/4daybandwidth.png 14:56 < jrandom> the sim had 32KB messages sent back and forth every 30s, with two routers choked at 6KBps, and things behaved exactly as they 'should' 14:56 < duck> (nolink property implemented for the site) 14:56 < jrandom> (e.g. load distributed over the fast reliable peers, slow peers avoided, etc) 14:56 < jrandom> w00t 14:56 < Connelly> a log plot of bandwidth/user vs network size would be nice 14:57 < Connelly> so you can say 'yeah, it really scales' 14:58 < jrandom> that wouldnt even need a log plot - the scalability of client comm is strictly O(1) [requiring 2k*msgSize, where k = # hops in the tunnel] 14:58 < jrandom> but yeah, I agree, we need some docs describing how i2p scales 14:58 < Connelly> well for kademlia ... is that in your sim? 14:58 < jrandom> yeah, the sim is actually the full blown router code, all run in a single JVM 14:58 < jrandom> i'm running it even with the full TCP connections instead of the VM comm system too 14:59 < jrandom> the kademlia code is used for the first time Alice wants to contact Bob - as long as they continue talking, their communication is O(1) as they bundle their LeaseSet along with the payload 14:59 < jrandom> (so there are no needs for subsequent netDb lookups) 15:00 < cervantes> vl07 and onb0 are the choked routers? 15:00 < jrandom> but yeah, we need a simulation to demonstrate how the netDb itself scales 15:01 < jrandom> cevantes: 0jvf and onb0 15:01 < cervantes> what accounts for vl07's dive after a days uptime? 15:02 < cervantes> seems to cross over with 00u0 15:02 < jrandom> all of the non-choked routers are essentially equal - they're all on the same CPU, all have the same (0ms) lag, so the allocation of one as 'fast' vs 'reliable' is just arbitrary 15:04 < Connelly> do your designations of 'fast and reliable', 'slow' etc recover from large values? 15:04 < jrandom> why did it reduce its ranking/usage after a day? i'm not sure, perhaps a transient cpu or io overhead while it was being tested caused its speed to reduce a bit 15:04 < jrandom> yes, the rankings use the median now, not the mean, plus there is a fiarly fast decay on the data 15:05 < jrandom> s/fiarly/fairly/ 15:05 < Connelly> so if i make you think my reliability is 1000000000, you can recover when i start dropping messages 15:06 < jrandom> certainly - if you 'fail' i immediately stop asking you to do things and decrease your ranking 15:06 < jrandom> the new "capacity" calculation in turn is quite sensitive to those types of changes 15:06 < jrandom> (speed is kind of hard to fake too, as all speed ranks are actual measured values) 15:07 < jrandom> ((as was the reliability, and as is the capacity calc)) 15:09 < jrandom> ok, anyone else have anything they want to bring up? 15:10 < deer> * jrandomi2p suggests the *baf*er 15:11 * jrandom concurs 15:11 * jrandom winds up 15:11 * jrandom *baf*s the meeting closed