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> <Nightblade> no trouble at all
14:08 < deer> <duck> 4d uptime with no problems
14:08 < jrandom> hmm, word
14:08 < deer> <duck> for some irc doesnt seem too stable
14:08 < deer> <duck> like kaji getting kicked ever minute
14:08 < deer> <duck> 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> <duck> yeah
14:09 < deer> <duck> connelly had some bad downloads afaik
14:10 < deer> <duck> 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> <duck> :)
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> <duck> 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> <duck> yes, that is my biggest problem with upgrading
14:14 < deer> <duck> (though I use cvs)
14:14 < deer> <duck> 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> <Nightblade> 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> <Sandworm> 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> <duck> this is your life
14:22 < modulus> so, when's 1.0 out? :-)
14:22 < deer> <duck> 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> <modulus>
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> <Nightblade> the website looks good
14:39 < jrandom> yeah, i like the new nav and the site layout is quite clean
14:40 < deer> <Nightblade> 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