<p>14:04 < jrandom> there are a few things adjusted since the 0.3.4.3 release came out last friday, but overall the rev seems pretty stable, from what i can tell</p>
<p>14:06 < jrandom> yeah, i do oOo, but thats why we have www1.squid.i2p :)</p>
<p>14:06 < jrandom> r0x0r</p>
<p>14:06 < jrandom> i've heard a few reports of excessive CPU usage - is that hitting people often?</p>
<p>14:07 < deer><hypercubus> not i... i suspect it's just the people with 386s *cough*lucky*cough*</p>
<p>14:07 < deer><oOo> Some very rare peaks here. Related to another erro, I might trace it back one day :p</p>
<p>14:07 < deer><mule> not here</p>
<p>14:07 < luckypunk> I think, if its affecting all platforms and stuff, i would feel it hard, and no not really. Only when its serving the new config pages or downloading a lot of stuff does I2P pin my processor.</p>
<p>14:08 < jrandom> ok cool. there are a few scenarios where i2p will be a bitch wrt CPU, but hopefully those are few and far between</p>
<p>14:08 < jrandom> actually, that leads us in to 1.1) timestamper :)</p>
<p>14:09 < jrandom> (one of the problems can occur when the timestamper gets goofy / loses track of the correct time)</p>
<p>14:10 < jrandom> the whole timestamping stuff has been revamped and integrated into the router, thanks to Adam Buckley being kickass and releasing his work under the BSD license</p>
<p>14:10 < jrandom> (yay Adam)</p>
<p>14:11 < jrandom> we had previously used the SNTP code as a standalone client app, but we are not doing that anymore - instead we have a tight integration with the router</p>
<p>14:11 < jrandom> (so people may need to update their config files as mentioned in the email)</p>
<p>14:11 < jrandom> SNTP alone is only a part of the solution though</p>
<p>14:12 < jrandom> long term we need some better (read: NTP) synchronization, as SNTP is prone to flux</p>
<p>14:12 < jrandom> (especially in light of high network congestion)</p>
<p>14:12 < jrandom> Adam sent me some code he has for dealing with it, but i dont really have the time to work through that side of things atm</p>
<p>14:13 < deer><oOo> Using SNTP only ?</p>
<p>14:13 < jrandom> i dont recall - i think it may be ntp-esque via sntp queries</p>
<p>14:13 < deer><oOo> Ok, thanks</p>
<p>14:14 < luckypunk> uh</p>
<p>14:14 < luckypunk> i have a suggestion about that..</p>
<p>14:14 < jrandom> anyway, if anyone ever feels bored and wants to do some crazy ntp hacking, that'd Rule</p>
<p>14:14 < luckypunk> or something similar.</p>
<p>14:14 < deer><oOo> That is what the current code do, more or less ;)</p>
<p>14:14 * cervantes catches up what he's mised</p>
<p>14:14 < luckypunk> oh.</p>
<p>14:15 < luckypunk> sorry.</p>
<p>14:15 < cervantes> missed</p>
<p>14:15 < deer><oOo> But we need variable seconds length & co ;)</p>
<p>14:15 < cervantes> cpu usuage on my system is the lowest it's ever been....</p>
<p>14:15 < jrandom> nice</p>
<p>14:15 < cervantes> but I've got 700 odd java threads now and rising</p>
<p>14:15 < jrandom> yeah oOo, and the skew detection / candidate selection</p>
<p>14:16 < luckypunk> yes, last time i ran it, about a month ago, it seriously affected my usability of my box, now i don't even notice if I2P is running.</p>
<p>14:16 < jrandom> yeah i've been looking into that cervantes</p>
<p>14:16 < deer><oOo> True, even if it's a weak part of the whole stuff ;)</p>
<p>14:16 < luckypunk> i have about 200 threads.</p>
<p>14:16 < luckypunk> 219, to be precise.</p>
<p>14:16 < jrandom> cervantes: i've tracked down the threads to the transport layer (we do some *uuugly* stuff to get timeouts), and we can do some better cleanup later</p>
<p>14:16 -!- TheCrypto__ is now known as thecrypto</p>
<p>14:18 < jrandom> basically some oddities are occurring with the increased # of peers on the network & the churn. all workable, but it can be annoying</p>
<p>14:18 < jrandom> anyway, thats it for 1.1, now 1.2) new router console authentication :)</p>
<p>14:19 < jrandom> (no one probably cares about this, but we have basic http authentication working. see the email for more info)</p>
<p>14:19 < cervantes> cool</p>
<p>14:19 < cervantes> despite that though the memory handling rocks... haven't had an oom in ages</p>
<p>14:19 < jrandom> ah wikked</p>
<p>14:20 < jrandom> actually, that gets us towards 2) 0.4 status</p>
<p>14:22 < luckypunk> Yes. If I2P were a MS product, we'd be ready for 1.0 :)</p>
<p>14:22 < jrandom> arggg, damn net connection dropped</p>
<p>14:22 < jrandom> (screen++)</p>
<p>14:23 < jrandom> ok, anyway, there has been a lot going on, and there are still a few more back end things left to do (some client tunnel pool management, as oOo is seeing, and some peer selection testing, as is in cvs)</p>
<p>14:24 < jrandom> there's also been a lot of progress on the installer / service / systray side of things </p>
<p>14:24 < jrandom> hypercubus: want to give us an update?</p>
<p>14:24 < deer><hypercubus> sure</p>
<p>14:25 < deer><hypercubus> the service wrapper installation is nearing completion, perhaps today or tomorrow... the service wrapper takes care of OOMs by automatically restarting the i2p router</p>
<p>14:25 < jrandom> (yay)</p>
<p>14:25 < deer><hypercubus> so it covers our butts there somewhat</p>
<p>14:26 < deer><hypercubus> systray integration is complete and works great... it's only for Win32 currently, since the systray4j lib seems to have some bugs in its KDE implementation</p>
<p>14:26 < deer><hypercubus> i'll be tracking the KDE progress and hopefully we'll have that in the near future</p>
<p>14:27 < deer><hypercubus> the installer is almost complete as well, all that remains to be added are post-installation tasks</p>
<p>14:27 < deer><hypercubus> i expect that will be done by the weekend</p>
<p>14:27 < deer><hypercubus> (as it depends on the complete integration of the service wrapper)</p>
<p>14:28 < jrandom> r0x0r</p>
<p>14:28 < deer><hypercubus> i'll be making available a pre-0.4 installer package for people to test</p>
<p>14:28 < deer><hypercubus> so i will let you all know when that's ready</p>
<p>14:33 < jrandom> ok, movin' on to 2.2) jbigi & jcpuid</p>
<p>14:34 < jrandom> iakin has put together some kickass JNI/asm code to detect the exact CPU architecture used (on x86 boxen), and he has jbigi rigged up for freenet to auto-select the right .so/.dll based on that</p>
<p>14:35 < jrandom> he has also released that work into the public domain, and we've snagged a copy and integrated it back into i2p</p>
<p>14:35 < luckypunk> So we won't have to chose which jbigi to download? Won't that make the install somewhat larger?</p>
<p>14:35 < jrandom> correct</p>
<p>14:35 < jrandom> yeah, it adds a few hundred KB</p>
<p>14:36 < jrandom> but, well, the new install is, um, larger than the old one</p>
<p>14:36 < luckypunk> oh, i thought it would be more than a few hundred kb.</p>
<p>14:36 < luckypunk> Yea, between the new console...I'm guessing 6 - 10 mb?</p>
<p>14:36 < deer> * Myo9 has only got 99 mb left on this drive.</p>
<p>14:36 < deer><Myo9> ;)</p>
<p>14:36 < jrandom> (especially since i'm being an ass and insisting on .war support rather than direct servlets, requiring xerces, which weighs in at 800KB)</p>
<p>14:36 < jrandom> the new install is looking ~4-6MB</p>
<p>14:37 < jrandom> but the good thing is, only ~1MB of that is i2p specific, so updates will be lightweight ;)</p>
<p>14:38 < deer><Myo9> I2P hasn't got much publication has it?</p>
<p>14:38 < deer><Myo9> Compared to freenet and TOR?</p>
<p>14:38 < protok0l> is download size a real consern? most people have broadband</p>
<p>14:38 < protok0l> i'm use it if it were 100megs</p>
<p>14:38 < luckypunk> protok0l, most people don't, actually. Most people that'd use I2P do. though i think I2P still supports dialup (sort of)</p>
<p>14:38 < deer><mule> for i2p users it shouldn't</p>
<p>14:39 < jrandom> in my view, the development effort is best served with gradual adoption after sufficient testing goes on at different crititcal points</p>
<p>14:46 < deer><oOo> Great ^^ Will play with it as soon as I manage to get my router back online ;)</p>
<p>14:47 < kaji> you could password the client download and roll it gmail style</p>
<p>14:47 < jrandom> hmm?</p>
<p>14:48 < kaji> small base + invitation only</p>
<p>14:48 < kaji> but that would take work</p>
<p>14:48 < jrandom> oh, for 0.4 release? </p>
<p>14:48 < kaji> oh, for the 1.0</p>
<p>14:48 < jrandom> no, not worth the effort atm. if we get flooded with new users we may want to look at using certificates, etc</p>
<p>14:48 < deer><oOo> 1.0 is for mass audience :p</p>
<p>14:49 < jrandom> well, for 1.0 we're going to be up past the 1000 user mark already</p>
<p>14:49 < jrandom> (at least, thats my hope ;)</p>
<p>14:49 * kaji thinks it would be fun to watch i2p go from 50 to 5000 node in 3 hours</p>
<p>14:49 < jrandom> heh</p>
<p>14:49 < deer><oOo> And then down to 100 ;)</p>
<p>14:49 < luckypunk> hypercubus, whoo hoo for americans! they're catching up ;)</p>
<p>14:49 < jrandom> heh, thats one way to test churn ;)</p>
<p>14:50 < cervantes> if aum gets stasher working...and hyper increases his goatse library then you'll see it jump 50 to 5000 is less than 3 hours ;-)</p>
<p>14:50 < kaji> and then 50100 as the nsa brings their node onlin</p>
<p>14:50 < jrandom> actually that kind of brings us forward to 3) AMOC vs. restricted routes</p>
<p>14:51 < jrandom> one of the interesting aspects of restricted routes is the ability to mount a 'sybil' attack really, really, really easily.</p>
<p>14:51 < jrandom> while mule was just mentioning a few minutes ago installing 50 new nodes, it'd be possible to bring online a significant number </p>
<p>14:52 < jrandom> one of the ways to address this is through a certificate authority, limiting the introduction of new routerIdentity certificates</p>
<p>14:52 < jrandom> another is through hashcash</p>
<p>14:52 < jrandom> another is through morphmix/tarzan style ip prefix detection</p>
<p>14:53 < jrandom> but, yet another is to say "fuck it" and hope we get sufficient 'good' peers to outnumber the 'bad' ones</p>
<p>14:53 < fvw> I think that's ok for the time being yes.</p>
<p>14:54 < protok0l> heres an idea</p>
<p>14:54 < jrandom> yeah, its the simplest thing to do, and adding artificial barriers to join a p2p network at this stage seems... foolish</p>
<p>14:54 < fvw> I think perhaps a mix of hashcash and ip-based would be nice to have for 1.0, but all in all you can't defend against a powerful enough adversary.</p>
<p>14:54 < protok0l> cut off the inital noderef access</p>
<p>14:54 < protok0l> if someone wants on, we can give them your noderefs</p>
<p>14:54 < protok0l> *uor</p>
<p>14:54 < fvw> and how would that help?</p>
<p>14:55 < jrandom> right fvw, and we might be able to put it off until after 1.0, as well</p>
<p>14:55 < fvw> depends on your definition of 1.0 :)</p>
<p>14:55 < jrandom> proto: i'm not sure that'd help much</p>
<p>14:55 < jrandom> heh fvw, we're not like freenet ;)</p>
<p>14:56 < deer><oOo> and well documented ;)</p>
<p>14:56 < jrandom> documentation is a prerequisite to secure :)</p>
<p>14:56 < deer><Myo9> Are all users added to the noderef at the moment?</p>
<p>14:57 < jrandom> Myo9: yes - http://dev.i2p.net/i2pdb/ is just a link into one of my router's netDb/ dir</p>
<p>14:57 < jrandom> (so it will list everyone my router has a reference for, at any time)</p>
<p>14:58 < jrandom> ((and everyone has a ref for people they talk to, which, at our current scale, is everyone))</p>
<p>14:58 < jrandom> ok, but back to 3) AMOC vs. restricted routes</p>
<p>14:59 < deer><Myo9> Ok.</p>
<p>14:59 < jrandom> as mentioned in the email, mule's ideas might be able to get us to drop the 0.4.2 AMOC transport and instead implement basic restricted route support, treating people behind NATs/firewalls as simply being behind a restricted route</p>
<p>15:00 < fvw> it would be kind of cool</p>
<p>15:00 < jrandom> yeah, and save us from writing yet another transport protocol</p>
<p>15:01 < deer><ugha2p> But how would make performing sybil attack that much easier?</p>
<p>15:01 < deer><ugha2p> how would it make*</p>
<p>15:02 < jrandom> ugha2p: there is no way to tell how many *real* routers are behind a restricted route - all we know about them is that they have a unique router identity and are reachable through a certain router</p>
<p>15:02 < deer><ugha2p> Ah.</p>
<p>15:03 < jrandom> that certain router could in fact be one sim instance, running 100 other routers in the same JVM, each pretending to be behind firwalls</p>
<p>15:03 < deer><ugha2p> Right.</p>
<p>15:03 < deer><oOo> They could as easily been using 100 ports on the same host...</p>
<p>15:03 < fvw> however assuming you're willing to spend a few 100 euros on your attack, you can get a large number of spread out IPs anyway.</p>
<p>15:03 < jrandom> agreed fvw</p>
<p>15:04 < jrandom> oOo: true, though ports cost memory (and some CPU)</p>
<p>15:04 < deer><ugha2p> I don't think that presumption is going to stop more powerful enemies though.</p>
<p>15:04 < jrandom> (which is why when i do larger sims, i need to switch from the TCP comm system to the VM comm system)</p>
<p>15:04 < jrandom> agreed ugha2p</p>
<p>15:04 < jrandom> it just makes it easier</p>
<p>15:05 < fvw> I think we're going to have to assume that anybody with more than a bored-sunday-afternoon desire to attack the system is going to be able to get at least 10^3 nodes on the network easy.</p>
<p>15:05 < deer><oOo> Not *that* much</p>
<p>15:05 < jrandom> right fvw</p>
<p>15:05 < deer><oOo> (+ easier)</p>
<p>15:05 < fvw> and at that order of magnitude, nothing apart from central certification is going to stop them.</p>
<p>15:06 < deer><ugha2p> 100 open ports on one single host would be trivial to detect, but 100 restricted routes behind a machine might not be.</p>
<p>15:06 < jrandom> well, thats open to debate fvw, but yeah, sybil is a bitch</p>
<p>15:06 < deer><oOo> 100 zombies are tricky to detect ;)</p>
<p>15:06 < fvw> which means we ideally need a 10^4 network.</p>
<p>15:06 < jrandom> definitely oOo</p>
<p>15:06 < fvw> (loose estimates)</p>
<p>15:07 < deer><ugha2p> We'll ideally have a 10^4+ network.</p>
<p>15:07 < jrandom> fvw: i'd go higher than that - imho we need to grow this into the millions</p>
<p>15:07 < deer><oOo> Ideally would be more then half available IPs ;)</p>
<p>15:07 < jrandom> heh oOo</p>
<p>15:07 < fvw> It'd be nice if we could yeah.</p>
<p>15:08 < jrandom> (but, of course, to grow it into hte millions we need sufficient reason to do so. i think we will be able to make the case for that eventually though)</p>
<p>15:08 < deer><ugha2p> I'm not sure if Kademlia could be held in one piece for that long. ;)</p>
<p>15:08 < fvw> at which point beating people up would definately become the low-cost attack. Which, unintuitively enough, would be a good thing.</p>
<p>15:08 < jrandom> heh</p>
<p>15:08 < deer><DrWoo> jrandom: millions would need serious useability and benefit</p>
<p>15:09 < jrandom> agreed DrWoo</p>
<p>15:09 < fvw> luckily, a lot of (non-nice) people are working very hard on that now.</p>
<p>15:09 < deer><oOo> Pr0n for masses :p</p>
<p>15:10 < deer><jrandom> which is why imho we need a kickass filesharing app</p>
<p>15:10 < deer><oOo> "One human, One goatse", which lead us to stasher :p</p>
<p>15:10 < deer><DrWoo> jrandom: it would have to be order of an anonymous kazza, luckily the motivation is being taken care of by the RIAA & co.</p>
<p>15:10 < fvw> pr0n is already easy to get (see usenet and such). I think big record company assocs and such are going to crack down a lot harder on p2p than pornographers ever could.</p>
<p>15:10 < cervantes> music</p>
<p>15:10 < fvw> but once again we drift offtopic.</p>
<p>15:11 < fvw> "4) stasher"?</p>
<p>15:11 < deer><oOo> Yeah ! 4) !</p>
<p>15:11 < jrandom> agreed - we can all think up some reasons to justify use, but first we need to get it *working* :)</p>
<p>15:11 < cervantes> ah for once a non-tenuous link into the next item</p>
<p>15:11 < jrandom> movin' to 4) stasher</p>
<p>15:12 < jrandom> aum: you awake yet?</p>
<p>15:12 * hypercubus chants auuuuuummmmmmmmm</p>
<p>15:12 < jrandom> well, in case he isn't, i know he's been doing a lot of work on adding CHK and SVK support to stasher</p>
<p>15:13 < jrandom> which is Cool</p>
<p>15:13 < deer><oOo> And splitfiles</p>
<p>15:13 < jrandom> yeah, the splitfile support is interesting</p>
<p>15:13 < fvw> in the 'interesting times' sense? </p>
<p>15:14 < jrandom> thats one of the differences between freenet and stasher, in that stasher already has a fixed 31KB max size per key</p>
<p>15:14 < deer><oOo> "Useful, great, don't need anything from user application"</p>
<p>15:14 < jrandom> (since afaik stasher uses SAM datagrams)</p>
<p>15:14 < luckypunk> can't you impliment lik..split files?</p>
<p>15:15 < jrandom> ooohhh! i just realized what bug he was running into wrt reliability! </p>
<p>15:15 < jrandom> (fixed the other day in cvs, significantly killing the bug)</p>
<p>15:15 < jrandom> yeah lucky</p>
<p>15:15 < jrandom> but the splitfile implementation is inherently different from how freenet splitfiles work, due to max keysize limitations</p>
<p>15:15 < deer><oOo> So Stasher over-I2P just be healthy again ? ^^</p>
<p>15:16 < jrandom> (if you read freenet devl or tech lately, you'll hear toad and hobx talking it over)</p>
<p>15:16 < deer><oOo> *should</p>
<p>15:16 < jrandom> oOo: with HEAD, yeah</p>
<p>15:16 * jrandom hasnt heard any reports of people even trying it since 0.3.4.3 came out (or was it 0.3.4.2)</p>
<p>15:16 < jrandom> but anyway, he is planning on another new test build by end of the week</p>
<p>15:17 < jrandom> anyone have anything to mention / discuss wrt stasher?</p>
<p>15:17 < jrandom> (other than yay! go aum!)</p>
<p>15:18 < deer><oOo> Yeah, there is an urge to find non-goatse contents there ;)</p>
<p>15:18 < jrandom> heh</p>
<p>15:18 < deer><oOo> ex-Freeneter, start your engines ;)</p>
<p>15:18 < jrandom> yeah splitfile support should definitely help with that, as would ssk & fcp support</p>
<p>15:19 < fvw> I'd like to second the 'go aum!' if I may.</p>
<p>15:19 < deer><oOo> yay !</p>
<p>15:19 < jrandom> motion is seconded, and thirded :)</p>
<p>15:19 < jrandom> ok, swingin' forward to 5) pages of note</p>
<p>15:20 < jrandom> i just wanted to point out three new pages</p>
<p>15:20 < jrandom> DrWoo's safe browsing guide gives a pretty good rundown on the dangers of eepsites & the outproxies</p>
<p>15:20 < jrandom> the problems can be addressed in code, but we just havent had time to do it yet, so its Good to be informed</p>
<p>15:21 < jrandom> lucky has also put together a good doc on the freebsd+java side of things as well</p>
<p>15:21 * jrandom hasnt tried too many jvms on fbsd, just kaffe, so nag him if you have questions :)</p>
<p>15:22 < jrandom> hyper has also put together the doc for upgrading to the 0.4 dev code, which he'll likely be updating once we want more people to test it ;)</p>
<p>15:22 < hypercubus> my post on the forum covers installation of the service wrapper... the howto for the new router console is here --> http://files.hypercubus.i2p/New_I2P_Router_Console_Howto.txt</p>
<p>15:23 < jrandom> wr0d</p>
<p>15:23 < jrandom> oh, there's also a new pretty picture & some new text @ http://www.i2p.net/how_intro (hopefully making things a bit more clear)</p>
<p>15:24 < fvw> ooh, that looks pretty. Who did that? Good work.</p>
<p>15:25 < hypercubus> it was actually copied directly from a crop circle</p>
<p>15:25 * fvw tries not to mention the resemblence between jrandom and Dave but fails miserably.</p>
<p>15:25 < jrandom> heh</p>
<p>15:25 < fvw> ah, that explains jrandom's feelers.</p>
<p>15:25 < jrandom> the pic was beautified by our anonymous designer</p>
<p>15:25 < jrandom> (thankfully so, my ms paint skills suck :)</p>
<p>15:26 < hypercubus> we're still trying to decipher the significane of Charlie's long chin</p>
<p>15:26 < deer><ugha2p> Arr, this sucks.</p>
<p>15:26 < jrandom> how about alice's skewed eyes? ;)</p>
<p>15:26 < hypercubus> heh</p>
<p>15:26 < deer><jrandom> yeah, it'll be nice when we get irc.duck.i2p upgraded (if it hasnt been already..)</p>
<p>15:27 < fvw> never mind that, she looks like she's doing a double alien-bursting-from-stomach-scene with her cheeks.</p>
<p>15:27 < jrandom> lol</p>
<p>15:27 < jrandom> *thats* why she is talking to dave</p>
<p>15:27 < jrandom> well, anyway, i think this leads us to 6) ???</p>
<p>15:27 < fvw> haha</p>
<p>15:27 < jrandom> anyone have anything they want to bring up?</p>
<p>15:28 < deer><oOo> Can't you build the skeleton of certificates' stuff in I2P and let *others* fill it and have fun ? (Or his this already done ? :p)</p>
<p>15:28 < deer><oOo> Or is this absolutely useless ?</p>
<p>15:28 < deer><oOo> (for now)</p>
<p>15:28 < jrandom> hmm? </p>
<p>15:28 < jrandom> the hashcash / etc certificate stuff?</p>
<p>15:29 < jrandom> ok yes, we already have the infrastructure for that</p>
<p>15:29 < jrandom> (though things like libSAM will need to be modified to interpret the destination properly, since iirc nightblade assumed 384bytes always ;)</p>
<p>15:30 < jrandom> but the router will handle different types of certificates transparently</p>
<p>15:30 < deer><oOo> The code is ready for this ? Just missing some 'content' ?</p>
<p>15:31 < jrandom> yes - the RouterIdentity created currently always attaches a NullCertificate (certificate type == 0)</p>
<p>15:31 < jrandom> if it attaches another type, another type of certificate is attached </p>
<p>15:31 < jrandom> e.g. hashcash cert, CA signed cert, etc</p>
<p>15:31 < jrandom> verification infrastructure is there as well (RouterInfo.verify)</p>
<p>15:32 < deer><oOo> Oh, great :)</p>
<p>15:32 < deer><oOo> So someone may play with this code and adding hashcash and stuff in advance ?</p>
<p>15:32 < jrandom> if we had a flash flood i could probably lock down the net in a day or two</p>
<p>15:32 < jrandom> right</p>
<p>15:33 < jrandom> (though i think fvw is right in that it wont be pressing for at least a little while)</p>
<p>15:33 < deer><oOo> Ok. I don't volunteer ;) But someone might :p</p>
<p>15:33 < Nightblade> on i2p.net, the aug 24 meeting log link is pointed at the aug 17 log</p>
<p>15:33 < jrandom> right, sorry, meeting isn't over yet :)</p>
<p>15:33 < Nightblade> oh haha</p>
<p>15:34 < jrandom> so, anyone have anything else they want to bring up? :)</p>
<p>15:34 < hypercubus> new rule... whoever edits the website: no smokin' the funny stuff while editing!</p>
<p>15:34 < jrandom> uh oh...</p>
<p>15:34 < jrandom> what'd i do?</p>
<p>15:34 < hypercubus> i was referring to broken links ;-)</p>
<p>15:34 < jrandom> oh</p>
<p>15:35 < hypercubus> we need a full time web editor... i nominate lucky</p>
<p>15:35 < jrandom> well, yeah, i updated the link to this weeks weekly status notes before the meeting, in case anyone went to the page ;)</p>
<p>15:35 < jrandom> we certainly do need someone to keep track of the web site and poke people when things are funky</p>
