14:07 < jrandom> 0) hi
14:07 < jrandom> 1) testnet status
14:07 < jrandom> 2) SAM
14:07 < jrandom> 3) roadmap updates
14:07 < jrandom> 4) MyI2P
14:07 < jrandom> 5) ???
14:07 < jrandom> 0) hi
14:07 * jrandom waves
14:08 < Nightblade> hi
14:08 * jteitel waves back
14:08 < jar> hi
14:08 < duck> lo
14:08 < Masterboy> :P
14:08 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2004-May/000239.html
14:09 < jrandom> sorry if I'm a bit out of it today, sleep schedule is more out of wack than usual
14:09 < jrandom> anyway, moving on to 1) testnet status
14:10 < duck> the diversification would automatically happen with a bigger network wouldnt it?
14:10 < jrandom> yes, and/or less skewed peer selection thresholds
14:11 < jrandom> for instance, if the speed threshold were the median as opposed to the average, we'd get half as many fast peers as reliable peers
14:11 < jrandom> as opposed to the situation we have today where the speeds are heavily skewed
14:12 < Masterboy> well the network healed that's not so bad
14:12 < jrandom> yeah, it took longer than it should though, and exposed ways that it can be improved
14:13 < jteitel> did the network heal? I still cannot connect to i2p irc reliably
14:13 < jrandom> the peer profiles didn't decay fast enough, or promote new candidates efficiently
14:14 < jrandom> it did fire off a chain of secondary events as well - overloading routers that weren't capable of holding the load (due to insufficient profiling), causing some overloaded routers to run out of memory and shut down
14:15 < human> ayeee ayeee ayeee!
14:15 < jrandom> its been a progression jteitel - some of the issues we've been seeing are related to the netDb failures
14:15 < jrandom> heya human
14:15 < jteitel> Oh, OK
14:16 < _cervantes_> could not an troubled router offload tunnels to another peer?
14:16 < ugha_node> Wow, Lifetime rate: 8.87KBps sent 8.35KBps received.
14:16 < Nightblade> jteitel: I connected just now after several tries...still waiting for my /join to go through
14:16 * BrianR looks around.
14:16 < jrandom> no - a router can simply drop a tunnel though (if it shouldn't have accepted it in the first place)
14:16 < ugha_node> (And I restarted my router half an hour ago)
14:16 < BrianR> damn it. I'm late.
14:17 < BrianR> jrandom: (Thanks for arranging myi2p towards the end of the agenda)
14:17 < jrandom> ugha> yeah, y'all had to pick up the slack for those three fast ones
14:17 < jrandom> hehe :)
14:18 < duck> a nice attack it was
14:18 < ugha_node> jrandom: Obciously.
14:18 < _cervantes_> so would it not be better to be more ruthless and reject tunnels at lower threshold
14:19 < jrandom> yes cervantes - the routers right now never reject a tunnel unless they cant reach the next hop
14:19 < jrandom> we'll want to include some sort of throttling in there, perhaps based on the size of the jobQueue / avg lag, etc
14:20 < jrandom> in addition, we'll want to make sure we dont try to build too many tunnels at once, as happened when a large portion of them failed
14:20 < _cervantes_> or simply allow the user to set a threshold based on the hardware/bandwith he/she knows he has availabled
14:20 < jrandom> (due to the fast+reliable peers going offline)
14:20 < _cervantes_> at least at this stage
14:20 < jrandom> oh thats a good point - allowing people to explicitly set a max # participating tunnels.
14:21 < jrandom> we'll get that into the next rev. good call.
14:21 < ugha_node> This sounds just like fuzzy logic.
14:21 < jrandom> we've got to deal with overload, and simply queueing up messages in memory certainly doesnt work
14:21 < duck> (hi fvw)
14:21 < _cervantes_> it would be good to have some kind of coalleted stats on tunnel performance... the kind of load the might inflict on a benchmark processor(s)
14:22 < _cervantes_> btw I took my server offline....it was getting a shed load of tunnels and I haven't yet compiled jbigi ;-)
14:22 < jrandom> see http://localhost:7655/routerStats.html#Tunnels
14:23 < jrandom> ah! yeah, jbigi is something we want to encourage everyone to use
14:23 < BrianR> Any thoughts on doing bandwidth budgeting for tunnels?
14:24 < jrandom> currently slated for 3.0 (with overall bandwidth limiting for the router as a whole @ 0.4.1)
14:24 < jrandom> but having per-tunnel bandwidth limits earlier wouldnt hurt
14:25 < fvw> Is it wise to spend effort on this so early when it's much easier and more precisely done in the kernel of the OSes most of the current users/testers are running?
14:25 < _cervantes_> something I would like to see is per-tunnel depth settings (perhaps this is already possible)
14:25 < _cervantes_> for instance I already know I can trust my server....so I don't want to have to go through _x_ hops to get to it
14:25 < jrandom> fvw> thats a good point, especially since we currently don't devour too much bandwidth
14:26 < jrandom> hmm cervantes - yes, each client can specify the length of their tunnels, but i'm not sure thats exactly what you want
14:26 < _cervantes_> nope
14:26 < jrandom> cervantes - i think what you're looking for is a QoS where you can shorten the conn for one particular peer
14:26 < _cervantes_> for instance...
14:26 < _cervantes_> yep
14:27 < jrandom> (which was slated for i2p 4.0, but thats more than a year away == infinity)
14:27 < _cervantes_> in this case also select the depth per i2p host
14:27 < BrianR> fvw: Yes, but an i2p needs to know roughly how much bandwidth potential tunnel members have available in order to make wise tunnelbuilding decisions...
14:27 < _cervantes_> ah ok
14:27 < _cervantes_> :)
14:27 < jrandom> but its a good idea, and technically feasible, but patches accepted :)
14:28 < _cervantes_> the patch is already in the mail....along with that cheque for 5000 bars of e-gold
14:28 < _cervantes_> ;-)
14:28 < jrandom> BrianR: perhaps it can go halfway - keep track of how many tunnels it is participating in, as well as how much bandwidth those tunnels are using, and use that as part of the decision as to whether to accept or reject a tunnel create request?
14:28 < jrandom> heh
14:30 < jrandom> ok, anyone have anything else for the testnet status?
14:30 < Masterboy> what about my paradox?
14:30 < Masterboy> :)
14:30 < jrandom> my plan is to get a 0.3.1.3 with the updates out by thursday or friday
14:31 < jrandom> Masterboy: i havent had time to go through your logs, but we'll have it resolved
14:31 < _cervantes_> friday 2005?
14:31 < _cervantes_> cool
14:31 < Masterboy> k
14:31 < jrandom> ok, moving on to 2) SAM
14:31 < Masterboy> now we know who is running the out of date router..
14:32 * jrandom hands the mic to our intrepid SAM.pm dev
14:33 < jrandom> (thats you BrianR :)
14:33 < BrianR> Hold a second.. :)
14:33 * duck cheers
14:33 < jrandom> in the meantime, dm or firerabbit around?
14:33 -!- Irssi: #i2p: Total of 26 nicks [0 ops, 0 halfops, 0 voices, 26 normal]
14:33 * jrandom checks the /names, nope. oh well
14:33 < jrandom> (no .net/C# sam lib updates then)
14:34 < duck> is the .py stuff still current?
14:34 < duck> or depricated by SAM improvements
14:34 < jrandom> not sure
14:34 < BrianR> Ok. I'm back.
14:34 < Nightblade> My C library appears to be working... I have not written an application to use it yet though
14:34 < jrandom> awesome nightblade!
14:35 < Nightblade> Has anyone here done GTK+/C programming under Windows?
14:35 < human> duck: the client lib needs a small change for versioning support
14:35 < _cervantes_> "hello world"?
14:35 < human> duck: the rest should work without problems
14:35 * jrandom suggests a datagram like tftp as the ideal sam test :)
14:35 < Nightblade> well, anything really... does GTK work well under windows.....?
14:35 < jrandom> (or even SAM streaming instead of datagram or raw)
14:36 < jrandom> cool BrianR - how goes the .pm and the samcat?
14:36 < BrianR> Net::SAM is in the CVS in mostly non-working form.
14:36 < BrianR> I hope to have all of the bugs ironed and datagram and raw working before week end.
14:37 < BrianR> A bit more work will be required to put a nice OO finish on streams.
14:37 < Nightblade> oh yeah, i didn't bother with datagram or raw... just stream
14:37 < Nightblade> but that is all i would use anyway
14:37 < fvw> human: Have you considered wxWindows? It's quite useful for that kind of stuff (don't think there's a windows GTK target though)
14:37 < jrandom> awesome BrianR
14:38 < BrianR> Wife is bugging me to join her for dinner. I may or may not be back in time for myi2p discussion. I've posted the threat model and stuff dumb fileserver stuff on node 208
14:38 < human> fvw: the GTK windows client does exist (The GIMP runs on windows, too)
14:38 < jrandom> cool nightblade, its best to implement whats needed first
14:38 < human> fvw: s/client/port/
14:38 < jrandom> heh 'k BrianR, thanks
14:38 < fvw> human: I mean gtk windows target for wxWindows (which I was suggesting you use)
14:38 * fvw waves to BrianR. Bon Appetite.
14:38 < human> fvw: ah... well, i don't know about vxWidgets (vxWindows' new name :-)
14:39 < human> fvw: but it was Nightblade speaking about GTK+, not me :-)
14:40 < fvw> Oops, my eyes are crooked, ignore me.
14:40 < Nightblade> I'm not as familiar with C++ as I am C
14:40 < Nightblade> afaik GTK is the only cross-platform C GUI library
14:40 < Nightblade> not that i am particularly fond of GTK
14:40 < fvw> doesn't really matter, wxWindows is easily approachable from C.
14:40 < Nightblade> hmm
14:40 < Nightblade> well maybe i'll take a look at it too
14:40 < Nightblade> i know C++ but I haven't written any major programs in it
14:41 * fvw isn't a C++ coder either, but I set up a fairly large transaction viewer for a transport company in it a while back without troubles.
14:42 < Nightblade> i am sure wxwindows has a more mature windows port
14:42 < Nightblade> than gtk
14:42 < fvw> quite probably yeah.
14:43 < Nightblade> (ok continue meeting) heh
14:43 < jrandom> :)
14:43 < jrandom> ok, jumping to 3) roadmap updates
14:44 * jrandom has been negligent updating http://www.i2p.net/roadmap over the last month
14:44 < jrandom> but now its back up to current
14:44 < jrandom> unfortunately we're obviously not getting 0.4 in next week
14:44 < duck> (are 1.1, 2.0, 3.0 also up2date?)
14:45 < jrandom> yessir
14:45 * Masterboy read it liked it - no rush we are not on fire..
14:46 < duck> someone should update wikipedia/infoanarchy too :)
14:46 < jrandom> oh, i should probably remove the "SAM bridge and client libraries implemented and tested" from 0.4
14:46 < jrandom> heh yeah, thats why i !thwapped iA a while back when they just copied the wiki page
14:46 < jrandom> (they should just point to the /roadmap, not duplicate the content)
14:47 < Masterboy> SAM is finished?
14:47 < jrandom> its functional yes, though work on additional client libraries are ongoing
14:47 < jrandom> s/are/is/
14:48 < jrandom> ok, unless there are any more roadmap questions/concerns, moving on to 4) MyI2P
14:50 < jrandom> while i've stopped working on myi2p myself, we've opened up the effort to a bounty - http://www.i2p.net/node/view/216
14:50 < jrandom> part of that means we need to get the requirements right, and there has been some debate about what those should be
14:51 < Masterboy> tried to get in it my friend he said too mutch work too little money;P well he is a capitalist;)
14:51 < Masterboy> well i offered to code it..
14:52 < jrandom> coding on it is always wanted :)
14:53 < jrandom> the current outstanding architectural question though is how to deal with people who cannot run their i2p router / myi2p node all the time
14:53 < Nightblade> just have to have some trusted i2p isp
14:53 < jrandom> the two proposals are either to use hosted service providers, or to split off the system to use a distributed backing store
14:54 < _cervantes_> the later being the long term ideal solution
14:54 < _cervantes_> *latter
14:54 < duck> (and being another bounty)
14:55 < _cervantes_> or a webcache proxy service...
14:55 < jrandom> right - if we went the hosted service provider (or locally run node), when a DHT/etc were available we could push more and more of the content into the DHT
14:55 < jrandom> _cervantes_: thats essentially the distributed backing store - untrusted data caches
14:57 < deer> * Masterboy wonders where is bogobot
14:57 < jrandom> the hard part is to get the access control functionality needed - with untrusted data caches / distributed backing store, ACLs are essentially encryption
14:57 < jrandom> but a "side channel" to this discussion comes from the three points raised by an anonymous person @ http://www.i2p.net/node/view/215#comment-105
14:57 < _cervantes_> and signed content
14:58 < jrandom> right, both ways will need to have signed content
15:00 < _cervantes_> this is where hypercubus' model has merit...but it's by no means "quick" solution
15:00 < jrandom> from the discussions on irc last night, we focused on the "livejournal threat model" - what attacks LJ users care about, and what they dont
15:01 < wilde> first things first, getting a basic MyI2P in first place
15:02 < jrandom> right, and to get the basic myi2p implemented, we've got to know the deployment architecture
15:03 < jrandom> with the lj threat model for users who cannot run their own nodes, i dont think we need to go the untrusted data cache route
15:03 < jrandom> and why would someone use myi2p if they merely need lj's threat model? because its anonymous
15:04 < jrandom> we could go on for some idealized system, but there is the law of diminishing returns
15:04 -!- Irssi: #i2p: Total of 24 nicks [0 ops, 0 halfops, 0 voices, 24 normal]
15:05 < jrandom> which is why i'm leaning towards keeping the bounty along the current lines - we can add on alternatives later, after the basic system is out
15:05 -!- duck_ is now known as duck
15:06 < jrandom> anyway, i think thats all i've got for 4) MyI2P, unless someone has anything else they'd like to bring up
15:06 < jrandom> if not, moving on to 5) ???
15:07 < _cervantes_> hmm you need a large gavel :)
15:07 < jrandom> i forgot to mention morph.i2p's new eepsite in the meeting notes, and nickster.i2p now has a public fproxy available!
15:08 < jrandom> (and sungo.i2p has his webcam up and running :)
15:08 < _cervantes_> heh...
15:08 < _cervantes_> i2pr0n
15:08 < jrandom> anyone else have anything they want to bring up?
15:10 < jrandom> if not, that'll put us at the 70 minute mark
15:10 < deer> <Masterboy> no
15:10 * jrandom winds up
15:10 * jrandom *baf*s the meeting closed