16:18 < jrandom> 0) hi 16:18 < jrandom> 1) Net status 16:18 < jrandom> 2) Fox hunt 16:18 < jrandom> 3) ??? 16:18 < jrandom> 0) hi 16:18 * jrandom waves belatedly from a house with its power restored 16:18 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-November/001227.html 16:19 < jrandom> 1) Net status 16:20 < jrandom> not much to add beyond whats in the mail.. anyone have anything they want to bring up re: net status? 16:21 < jrandom> if not, movin' on to 2) Fox hunt 16:21 < zzz> great idea 16:22 < jrandom> here, too, I don't have much to add beyond whats in the mail and Raccoon23's proposals.. 16:22 <+fox> I have something against the name "Fox hunt". I'd rather call it "Man hunt". Foxes did nothing wrong. 16:22 < Raccoon23> hah 16:22 < jrandom> aye, I concur zzz, it'll be quite helpful to give people a real incentive without the serious dangers of actual use 16:23 < nickless_head> call it " hunt 16:23 < Raccoon23> "Fox hunt" is the typical name for a ham radio contest where you try to find a rogue transmitter 16:24 <+fox> I don't care for radio trasmitters called Fox, we're talking i2p here, no anonymous foxes allowed 16:24 <+fox> :D 16:24 * cervantes wonders if ailouros is aware of the name of changate 16:24 < nickless_head> maybe "Dissident hunt" 16:25 <@cervantes> :D 16:25 <+fox> (err what's changate?) 16:25 < jrandom> heh 16:25 <@cervantes> ailouros: it's the bots that relay chat between different networks 16:26 <+fox> you mean vulpine here? 16:26 <@cervantes> chat over on i2p gets relayed to you as vulpine 16:26 <@cervantes> and you chat is relayed to us via fox 16:26 <@cervantes> ;-) 16:26 <@cervantes> *your 16:26 <+fox> so the hunt is for the poor slave-working bot? :D 16:27 < Raccoon23> so yeah, I think there should be a bounty/info page set up. I think we should shoot for raising $1k 16:27 <+fox> yeah sorry I don't usually go i2pchat :) 16:27 <+fox> now, that's a bounty! 16:28 < jrandom> Raccoon23: I agree, but it may be a bit premature to do so now. 16:28 < jrandom> (we can always allocate funds out of the general fund to the bounty to kick start it when necessary) 16:28 <+fox> start the hunt right now but without a bounty? 16:28 <+fox> I mean, the sooner it starts, the more eyes get open 16:28 < jrandom> for the fox hunt to make sense (aka help I2P), we need to do so carefully. 16:28 < jrandom> no ailouros, I disagree. 16:29 < jrandom> running the contest before I2P is ready would be very bad. 16:29 < Raccoon23> yah 16:29 < jrandom> both because it would waste people's time evaluating something that isn't done, and because it wouldn't tell anything useful 16:30 <+fox> ....point taken 16:30 < Raccoon23> and it would be bad press if vulns were "found" that were scheduled to be fixed in coming versions 16:30 < jrandom> aye 16:33 < jrandom> ok, anything else on 2), or shall we move on over to 3) ??? 16:34 < zzz> on the other part of the jrandom/raccoon23 thread, was it a conclusion to move to 2-hop-minimum? any other conclusions? 16:35 < jrandom> hmm, its all a question of who one's adversary is, but it wouldn't really hurt to default to 2 +0-1 and would afford protection against a class of attacker 16:35 < jrandom> other conclusions may be "hey, get rolling on 0.6.2" :) 16:35 <+fox> how do I set the configuration so that the tunnels always have a set value (like 0+1 variance)? I keep getting default values every restart 16:36 < jrandom> ailouros: you should be able to save the settings on /i2ptunnel/ 16:36 < jrandom> or are you changing them on /configtunnels.jsp ? 16:37 < Raccoon23> I think 1 hop tunnels allow a pretty weak attacker to do a lot in 0.6.1 at least. I would argue that 0.6.1.6 should not have 1 hop tunnels by default 16:37 <+fox> configtunnels it is 16:37 < jrandom> aye, agreed Raccoon23 16:37 < jrandom> ailouros: use /i2ptunnel/ and save your settings 16:37 <+fox> didn't notice the new interface :D 16:38 <@cervantes> ailouros: just added in 0.6.1.5 16:38 < jrandom> yeah cervantes did some great work there ailouros 16:38 <+fox> well, kudos for that 16:39 <@cervantes> while we're on that subject, if folk are having troubles saving settins on the new interface, they might want to use a non-IE browser for now until the next release 16:39 <@cervantes> *grumble* microsoft *grumble* 16:40 <+fox> on a different topic, would anyone be interested if I set up a nethack server on i2p? :D 16:41 <@frosk> ailouros: been thinking about it (playing nethack irl), but the lag would be horrible i'm afraid (and lag sucks really hard when playing nethack) 16:42 <+fox> guess so 16:42 <+fox> okay, idea scrapped 16:43 * frosk just had his first ascension a few months back, woot 16:44 < jrandom> ok, anyone have anything else for the meeting? 16:45 <+fox> yes, some indicator for syndie wen the thread has a new message 16:46 < nickless_head> jrandom: and it would be cool if new messages (the titles) could be printed in bold/italics the first time they're displayed 16:47 < nickless_head> jrandom: is there a _really simple_ way to get to the messages in the syndie database, over http? 16:47 < jrandom> ah yeah ailouros/nickless_head, I'm thinking of color coding/flagging the first column by date (e.g. things posted today get a bright flag, yesterday a less bright, etc). 16:47 < nickless_head> jrandom: preferredly in something nice and importable like xml 16:48 < jrandom> nickless_head: wget -R http://localhost:7657/syndie/archive/ 16:48 < nickless_head> if there is, I could write a syndie to nntp exporter 16:48 < jrandom> oh, if you want to export to nntp, use rss to nntp 16:48 < nickless_head> jrandom: ok I'll try that :) 16:48 < nickless_head> jrandom: that already exists? ... damn. ;) 16:49 < jrandom> i'm also thinking about adding per-user message histories to let you mark messages as read/unread, but that probably won't be in 0.6.1.6 (unless someone else implements it :) 16:49 < jrandom> or perhaps a new filter on the thread tree - only show messages posted since [today |v] 16:49 < jrandom> (or yesterday, or 2 days ago) 16:50 < jrandom> nickless_head: http://www.methodize.org/nntprss/ 16:50 < nickless_head> jrandom: thanks 16:54 < jrandom> np 16:54 < Raccoon23> jrandom: so it'd be a while before I'd be able to implement it (I wanna get restricted routes done first), but what do you think about optional 1024bit garlic routing for outbound server tunnels? 16:54 < jrandom> tremendous overhead - O(data) is >>> O(tunnels). if we're running into trouble now with O(tunnels), there's no way we can hope for O(data) 16:55 < Raccoon23> are we still having cpu issues? my router has been pretty low, but I don't exactly have a T1 over here.. 16:56 < jrandom> not everyone has p4s ;) 16:56 < jrandom> i hear reports of 8-15% usage on slow machines, but that spikes bad under congestion 16:56 < jrandom> (to 100+%) 16:56 <+Complication> About CPU consumption: curiously enough, Java on Mandriva 10.1 consumes a lot less than Java on Mandriva 2006. 16:56 < Raccoon23> yah, but those who don't probably don't have T1 16:56 < Raccoon23> either :) 16:57 <+Complication> Both tweaked, 2006 has jbigi compiled locally. 16:57 < jrandom> weird Complication 16:57 < jrandom> same revs of i2p? 16:57 <+Complication> On 2006 (Celeron 2.4) java can hit 20%. 16:58 <+Complication> On 10.1 it wouldn't go higher than 5%. 16:58 <+Complication> (Usually) 16:58 <+Complication> (usually==not on startup) 16:58 <+Complication> Same revisions. 16:58 <+Complication> Almost the same Java too (_04 versus _05) 16:59 <+Complication> Reminds me to tweak daemons a bit more. Perhaps some of them is obstructing java. 16:59 <+Complication> In some wacky way I cannot figure out. 17:00 <+Complication> But yes, the Cel 300 is feeling notably better. Could have been the adaptive MTU 17:01 < jrandom> ah cool, yeah, we've got some neat stuff on the way :) 17:03 <+Complication> I wonder if there'd be a way to get past the libc-related jbigi problems on certain Linux distros? 17:03 < jrandom> yeah, definitely, just need to rebuild all the jbigis 17:03 < jrandom> (its not libc, its libg++) 17:05 * Raccoon23 decides he doesn't give up his dreams of garlic routing, but will wait for performance to stabilize.. perhaps 2.0 17:05 <+Complication> Oh, you think a proper rebuild will help it? 17:05 < jrandom> Complication: yeah, the jcpuid link errors are unnecessary, as jcpuid is really just an ASM call (and shouldn't have been implemented in c++ anyway ;) 17:06 < jrandom> Raccoon23: cool :) its something we can do eventually over the live net too, just using a different I2NP message type, advertising the right capability, and filtering on that 17:06 < jrandom> (eventually) 17:07 < Raccoon23> like a caps=S for speedy CPU? ;) 17:08 < jrandom> and caps=I for insane ;) 17:08 < jrandom> ok, anyone else have something for the meeting? 17:08 < Raccoon23> haha 17:09 < Raccoon23> what do you think about the stopgap of sharing keys across multiple tunnels? too little payoff for the work? 17:09 < jrandom> why would that be better than just having multiple tunnels and sending the message through one of the multiple tunnels? 17:10 < jrandom> (and, erm, wouldn't it be worse, from a security perspective, and anonymity perspective) 17:10 < Raccoon23> well the idea is that nodes could not tell which traffic was part of one tunnel, so that if you were running i2phex and and eepsite, and choose the same hosts for your tunnels, the traffic from the two would be blended as far as the hops could see 17:11 < Raccoon23> which should make timing attacks harder 17:11 < jrandom> ah, yikes, yeah. that adds Really Bad linkability 17:11 < jrandom> its why we moved to per-client tunnel pools in 0.4 17:11 < Raccoon23> explain? 17:11 < jrandom> i2ptunnel does let people share pools, if they want, by sharing the same destination 17:12 < jrandom> if messages for 2 clients go down a tunnel, you know both of those clients are controlled by the same person 17:12 < jrandom> s/clients/destinations/ 17:13 < Raccoon23> well if keys were shared, the early hops could be blended, but the leasesets seperate.. 17:13 < Raccoon23> the early hops being the dangerous ones for timing attacks anyways 17:13 < jrandom> it'd still allow a vector for linking the two unlinkable destinations 17:14 < jrandom> one could do some munging to hopefully obfusticate the linkability, but they'd be inherently linked. which isn't necessary, and is bad. 17:18 < Raccoon23> back to dreaming of caps=SI I guess :) 17:19 < jrandom> ah well. ok, anyone have anything else? 17:20 * jrandom winds up 17:20 * jrandom *baf*s the meeting closed