13:07 < jrandom> 0) hi
13:07 < jrandom> 1) Net status
13:07 < jrandom> 2) 0.5 status
13:07 < jrandom> 3) i2p-bt 0.1.7
13:07 < jrandom> 4) ???
13:07 < jrandom> 0) hi
13:07 * jrandom waves
13:07 <+ugha2p> jrandom: Is irc.duck.i2p also available on the testnet and linked to this network?
13:07 <+ugha2p> To this IRC network
13:07 < jrandom> weekly status notes posted @ http://dev.i2p.net/pipermail/i2p/2005-February/000575.html
13:07 < ant> <Sonium_> Bonjour, sa cette fois de la semaine encore,
13:07 < jrandom> no ugha2p
13:08 < ant> <Sonium_> are you speaking french jrandom ?
13:08 < jrandom> heh, yeah, proof that babelfish has its limits ;)
13:08 < jrandom> lol, yeah, people were saying babelfish was turning out ok french before, but aparently not this time ;)
13:09 <+ugha2p> Hi fellow I2Pers.
13:09 < ant> <fedo2p> hi
13:09 < jrandom> anyway, lets get this underway before we netsplit again
13:09 < jrandom> 1) net status
13:09 < jrandom> see the email for an update
13:10 < jrandom> it seems that while irc has been pretty bumpy, as has some outproxy activity, bt has been doing pretty well
13:11 < jrandom> i don't really have much more to add beyond that though - anyone have any comments/questions/concerns?
13:12 < ant> <Sonium_> will 0.5 be released this friday?
13:12 < jrandom> heh good question, I suppose that can bring us on to 2) 0.5 status
13:12 < jrandom> yes, 0.5 will be released this friday
13:13 < jrandom> the test network is doing pretty well with the latest updates, but there's still some doc and minor cleanups left to do. i'm also going to try to get the latest jetty in there, but we'll see
13:14 < ant> <Sonium_> a question for a native english speaker: what is the semantical difference between "it will be released" and "it is going to be released" ?
13:14 < bla_> Routing seems to be a little bit of a problem sometimes; in, say 5-10% of the cases, I have to reload a page, because the tunnel isn't working well
13:14 < smeghead> i'd like to request that everyone involved in bittorrent activity voluntarily cease until 0.5 is released on friday since the surge in bt traffic is ruining the rest of the network traffic, especially irc
13:15 < jrandom> Sonium: the later is more definitive, but same general idea
13:15 < bla_> smeghead: I'd agree, but 0.5 will not solve the load problem, will it?
13:15 < smeghead> eepsites are affected too, not just irc
13:16 < ant> <Sonium_> ok, than it missunderstood the usage till now
13:16 <+ugha2p> jrandom: Will it be doing a better job with interactive traffic?
13:16 < jrandom> 0.5 will change a lot of dynamics, and should be able to more cleanly handle load balancing, as we can now differentiate between the different causes of tunnel rejection
13:16 < ant> <Sonium_> I better would have listened up at school
13:16 < jrandom> ugha2p: yes, substantially
13:17 <+ugha2p> Ah, cool.
13:17 < jrandom> otoh, there will be an overal increase in bandwidth usage for many situations, though we will improve upon that later as things progress
13:18 < smeghead> and someone please let our new french speaking users know about this and ask them to hold off the bt stuff until friday
13:18 < ant> <BS314159> smeghead: it's three days. I'm sure you can come up with something else to do for three days
13:19 * jrandom could poke open an inproxy to spaetz's 0.5 ircd :)
13:20 < jrandom> perhaps a simpler solution would be to suggest bt users take advantage of the capacity to reduce network load by reducing their tunnel length
13:21 < jrandom> (both on the inbound tunnels, as configured with the bt command line, and on outbound tunnels, as configured on http://localhost:7657/configclients.jsp )
13:21 < polecat> Yeah, they don't need so much anonymity as obscurity. It's us illegal alien ferrets that need the 2 hop thingy.
13:21 < bla_> jrandom: A possible solution, bt-0.1.8, wiith default tunnels length of 1, was mentioned before here on the channel. Duck, you here?
13:22 < polecat> Does i2p-bt use SAM, or does it use an i2ptunnel session?
13:23 < jrandom> hmm, otoh there are a whole set of new i2cp session options we'll want exposed in the i2p-bt, so i'll need to get in touch with duck about an updated release anyway
13:23 < jrandom> polecat: SAM
13:23 < smeghead> BS314159: i'm a contributor to not only i2p codebase, but also i2p-bt, this bt traffic is preventing me from communicating with the other devs and impeding our efforts to improve everyone's experience, have some consideration please
13:23 < smeghead> BS314159: is it more important for you to torrent than it is for us to develop
13:23 < smeghead> ?
13:23 < smeghead> polecat: sam
13:23 < cervantes> make 0.1.8 shop all it's users to the mpaa and we'll all stick with 0.1.7
13:23 < smeghead> bla_: there probably won't be a 0.1.8, we've got 0.2.0 in cvs now, a new codebase based on bt 3.9.1
13:23 < jrandom> heh cervantes
13:23 < jrandom> ooOOo nice
13:24 < jrandom> perhaps thats a good segue from 2) 0.5 status to 3) i2p-bt :)
13:24 < jrandom> smeghead/duck, how goes?
13:25 < ant> <Sonium_> google knows 167 links to www.i2p.org
13:25 < bla_> jrandom: Maybe the upgrade timeline should be reiterated: take yer eepsite offline on Thursday evening (UTC), upgrade on Friday, and fire up the eepsite when a sufficient number of users have upgraded
13:26 < ant> <Sonium_> erm .net
13:26 < smeghead> all the bt mods in 0.1.7 have been integrated into the new 0.2.0 codebase
13:26 < smeghead> but we have to write a completely new sam interface, we can't use the one from 0.1.7
13:27 < jrandom> ah ok
13:27 < smeghead> if there's anyone with python socket experience that would like to help *cough*connelly
13:28 < polecat> All that's happening in SAM is the addition of stream level choking, right?
13:28 < jrandom> polecat: no protocol changes yet (to my knowledge), just porting
13:28 < smeghead> please get in touch with duck
13:28 < ant> <MANCOM> anything new on azneti2p?
13:28 < smeghead> the 0.2.0 client will handle multiple torrents all in one instance, you won't have to open multiple sessions anymore
13:29 < jrandom> (yay!)
13:29 < polecat> Reeeally?
13:29 < smeghead> and hopefully we can get it all working over a single sam session to further reduce network clutterage
13:29 < bla_> smeghead: Nice! Will you also port the text-onlu bttrackmany?
13:29 < polecat> Can it run in the background?
13:29 < jrandom> MANCOM: I haven't heard any news, and unfortunately haven't had time to audit the updates
13:29 < polecat> How much memory does it sit on?
13:29 < smeghead> bla_: yes i believe so
13:30 < smeghead> polecat: using btdownloadheadless.py it's a background process
13:31 < polecat> A single SAM session is possible: the peerwire and tracker protocol can be divined by both the client and server.
13:31 < polecat> smeghead: Yes, but what if I want to add a torrent to that process?
13:32 < smeghead> polecat: and it shouldn't use significantly more memory than the comparable number of 0.1.7 instances do
13:34 < jrandom> polecat: its a port of the mainline BT, it works just like the mainline BT. someone could add new and better features, but lets start with a plain port first ;)
13:36 < bla_> (Connection rollercoaster ride, again...)
13:36 < jrandom> (this is why I lightly edit the meeting logs ;)
13:37 < bla_> jrandom: :)
13:37 < jrandom> wb
13:37 < polecat> smeghead: Yes, but what if I want to add a torrent to that process?
13:38 <+ugha2p> jrandom: No, it must be because you're censoring the netsplits.
13:38 < jrandom> polecat: its a port of the mainline BT, it works just like the mainline BT. someone could add new and better features, but lets start with a plain port first ;)
13:38 < jrandom> hey, if i censor the netsplits, they dont happen!
13:38 * jrandom buries head in sand
13:40 < smeghead> but i will use this opportunity to again ask bt users to hold off until friday please
13:41 < bla_> Right, if there's anyone who speaks French here, you don't have to say anything now, but please add a message to the effect of what smeghead asks to the French sections of forum.i2p ...
13:42 <+polecat> At any rate, I've missed the chance to say but, I was thinking of instead of a bt client in C++, I could just fix the mldonkey bittorrent plugin, and use that.
13:42 < ant> <dm> I speak french.
13:43 < ant> <dm> awww shit, I was supposed to not say anything.
13:43 * jrandom flings mud at dm
13:43 < bla_> dm: Could you add those messages?
13:43 < smeghead> there's nothing wrong with torrenting, but then again such a sudden increase in the number of i2p users wasn't expected and clearly the 0.4.x network can't handle it well
13:43 <+polecat> Unless someone else had an idea for something better I could waste my time on. :/
13:44 < ant> <dm> don't have i2p on here, I'm afraid. I can translate english->french if u msg me what needs to be said.
13:44 < jrandom> polecat: perhaps help out getting the upcoming i2p-bt to work as you'd like?
13:44 < jrandom> dm: forum.i2p.net/
13:44 <+polecat> jrandom: I think the main bt isn't very useful myself, and is doomed to be a stopping block for multiple torrent system, unless they switch to a client/server UI.
13:44 <+polecat> Which I might add, mldonkey/mlnet has already done.
13:44 < smeghead> polecat: mldonkey is a horrid, horrid mess, please help on the i2p-bt project or the azureus-i2p project, they could use a hand
13:44 < ant> <BS314159> polecat: I think it's a waste of time to reimplement i2p-bt in a faster language, given the overhead in I2P
13:45 <+polecat> And I was planning to do with this stupid C++ client thingy o' mine.
13:45 < jrandom> polecat: so put on a gui, giving you the benefit of the underlying i2p-bt code
13:45 < ant> <BS314159> but having the use of the MLDonkey interface might be a very good thing
13:46 <+polecat> Azareus doesn't separate UI from file transfer I dun' think. :/
13:46 < smeghead> polecat: you need to try bt 3.9.1, it's a multitorrent client now
13:48 <+polecat> Does it allow you to quit the UI without quitting swarming your files?
13:48 < jrandom> there are some features that it doesnt do well, that azureus does well, though there are also some environments where azureus isn't the right solution
13:48 < ant> <jnymo> has azureus released a compatable binary for the plugin?
13:48 < jrandom> polecat: no. but adding that is trivial compared to writing a new bt client
13:48 < jrandom> jnymo: yes, they have a beta azneti2p
13:49 < smeghead> polecat: it could easily be modified to do so, very easily in fact
13:49 < jrandom> polecat: just modify the existing bt daemon to allow other processes (aka your new GUI) to tell it to do things
13:49 <+polecat> Well, perhaps...
13:49 <+polecat> You think so?
13:49 <+polecat> Maybe if I wrote a UI that was just an RPC socket protocol, and then... I'd have to write a whole client to grok that protocol...
13:50 < smeghead> polecat: you don't have to write a new ui, mod the existing i2p-bt 0.2.0 ui to do it, it's simple
13:50 <+polecat> Maybe we could separate the UI part of bt and the daemon part, and run those pieces as separate processes without having to rewrite too much code!
13:50 <+polecat> Okay.
13:50 <+polecat> I have one more question though...
13:51 < smeghead> polecat: don't reinvent the wheel because something lacks trivial features
13:51 < smeghead> polecat: you haven't looked at the i2p-bt codebase at all have you? the ui is completely separate
13:51 <+polecat> If bittorrent 3.9.1 is out, why are we using version 0.2.0 in i2p? o.o
13:51 < jrandom> heh
13:51 < jrandom> i2p-bt 0.2.0 == bt 3.9.1 :)
13:51 <+polecat> I looked at the codebase a while ago. It was quite convoluted and obfuscated.
13:51 < jrandom> (i2p-bt 0.1.* == bt 3.4.something i think)
13:51 <+polecat> Oh, you have different versioning.
13:52 <+polecat> Is i2p-bt on CVS?
13:52 < smeghead> polecat: 0.2.0 is a new branch in cvs i created yesterday, it's i2p-bt, the official bt version it's based on is 3.9.1 which will be bittorrent 4.0 when it's out of beta
13:52 < jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p-bt/
13:52 < smeghead> i2p-bt 0.1.7 is bt 3.4.2 based
13:52 <+polecat> Thanks.
13:52 <+polecat> Wait.
13:53 < cervantes> at which point we'll call it version 0.3.0 :P
13:53 <+polecat> I meant CVS, not the "ooh lookit the pretty website CVS"
13:53 < jrandom> cvs -d :pserver:anoncvs@cvs.i2p.net/cvsroot co i2p-bt
13:53 <+polecat> CVSROOT= is noticeably absent on those cvs-cgi thingies I've noticed.
13:53 < jrandom> or, if you have the CVS proxy locally, cvs -d :pserver:anoncvs@localhost/cvsroot co i2p-bt
13:54 < smeghead> polecat: convoluted? btdownloadgui.py is all the gui code, how can you get more cleanly separated than that?
13:54 * polecat whews, and doesn't feel a burning desire to bitch about CVS now.
13:54 < ant> <dm> ugh, that was painful, haven't written anything in french for years! http://forum.i2p.net/viewtopic.php?p=1238#1238
13:55 < jrandom> thanks dm
13:56 < ant> <dm> np
13:57 < smeghead> it probably says something obscene
13:58 < ant> <dm> hehehhe
13:58 <+polecat> Alright, so I have to write btdaemon.py, which is the gui - all gui stuff. And also btdaemongui.py, which is the gui - all daemon stuff.
13:58 < ant> <BS314159> if it's sufficiently obscene, it may serve our purposes just fine
13:58 < ant> <fedo2p> good job dm ;)
13:58 < jrandom> heh
13:58 < jrandom> r0x0r polecat
13:59 <+polecat> Sigh, I hate to emerge wxwindows though, it's a big library I don't normally use. Oh well.
13:59 < smeghead> polecat: 0.2.0 is gtk based, no more wxwidgets
13:59 < jrandom> ok, lots of bt work to do, perhaps we can discuss further on the list/forum/wiki/#i2p-bt as necessary?
13:59 <+polecat> If I'm gonna be hackin', I best get the toolz
14:00 <+polecat> Oh I forgot about that channel. :)
14:00 < smeghead> polecat: get bittorrent 3.9.1 beta and read the docs
14:01 < smeghead> #i2p-bt, right
14:01 < smeghead> there's even people there
14:02 < jrandom> heh ok, lots of exciting bt stuff. anything else for 3) i2p-bt, or shall we move on to 4) ???
14:03 < jrandom> ok, moving to 4) ???
14:03 < jrandom> anyone else have anything else to bring up for the meeting?
14:03 < ant> <jnymo> threshold crytography rules
14:04 < cervantes> ??? = http://forum.i2p/viewtopic.php?p=1237
14:04 < ant> <BS314159> proxies to the web are not cool. What about proxies to new versions of I2P, or other anonymnets?
14:04 < ant> <BS314159> and by not cool I mean not safe to run
14:04 < ant> <jnymo> they aren't run by everyone, BS
14:05 < ant> <BS314159> I know that
14:05 < cervantes> Forum member of the week is <tadaa!> jrandom
14:05 < ant> <BS314159> I'm thinking about upgrades
14:05 < jrandom> lol thanks cervantes
14:06 < ant> <BS314159> Not now, but eventually, would it be possible to have a large number of routers act as inter-version proxies?
14:06 < ant> <BS314159> and would that remove the timing attack without downtime?
14:06 < ant> <jnymo> forced upgrades are necessary
14:07 < ant> <BS314159> I disagree
14:07 < jrandom> BS314159: I2NP over i2ptunnel over I2P would be, painful. though perhaps one of the "outproxies" could point at some inproxy
14:07 < jrandom> BS314159: while forced upgrades aren't generally necessary, they are here. period. we need it, because I didn't forsee all of the changes we need for 0.5
14:08 < ant> <BS314159> I'm not saying new versions should be backwards-compatible
14:08 < cervantes> jrandom: well lets be honest...you're the one that does 98% of the work ;-)
14:09 < ant> <BS314159> I'm just trying to come up with a way to allow non-nimble I2P users to upgrade without timing attacks or downtime
14:10 < jrandom> BS314159: can't be done for the 0.5 release. later releases we can be careful. but for this one, its a drop dead cutoff.
14:10 < ant> <jnymo> automatic update may be better in the future
14:10 < ant> <BS314159> I'm speaking about the far future.
14:10 < ant> <jnymo> is auto-update too insecure?
14:10 < jrandom> cervantes: nah, only 95% of the infrastructure, but there's a lot more goin' on than just i2p/{core,router}/ :)
14:11 < jrandom> jnymo: 0 click update == insecure. 1 click == safe.
14:11 < cervantes> jrandom: yes it's begun to pickup over the last couple of months thankfully ;-)
14:11 < ant> <jnymo> and a line that says "you need to update.. countdown in * days"
14:12 < jrandom> aye, lots of people [http://www.i2p.net/team] have been doing kickass shit
14:13 < jrandom> BS314159: definitely lots we can do for later updates, perhaps we can discuss concrete impls as they approach :)
14:13 < jrandom> ok, anyone else have anything to bring up for the meeting?
14:13 < ant> <MANCOM> could we have some kind of autospeed feature (like with the azureus plugin that measures ping times) in i2p that adjusts the maximum (upload-)bandwidth?
14:14 < ant> <MANCOM> it would help keep bandwidth up and latency down
14:14 < jrandom> oh, interesting
14:14 * cervantes is working on a 1-2 click update feature for the i2p toolbar
14:14 < cervantes> although I'm having problems with hashing atm....so it's probably a few weeks away.
14:15 < ant> <jnymo> cervantes++
14:15 < jrandom> MANCOM: if you could doc up how it'd work and look, and post that on the forum, that'd be great. if its simple enough, might even make it into 0.5
14:15 < cervantes> in which time a dozen people will come up with a glut of better solutions
14:16 < jrandom> heh
14:16 < cneal92_> :D
14:17 < ant> <MANCOM> well, i'll try
14:17 < ant> <cervantes> but it already detects when there's a new release out, and can point you at the relevant download link...
14:17 < ant> <cervantes> which I may roll with initially
14:18 < jrandom> cool cervantes
14:18 < jrandom> thanks MANCOM
14:18 < ant> <jnymo> you could just put the "graceful restart" button to upgrade, after the update is already in the directory
14:19 < ant> <jnymo> or call it "upgrade"
14:19 < ant> <jnymo> and put the restart function in there
14:19 < ant> <jnymo> though i'm probably stating the obvious
14:19 < jrandom> right, we need perhaps a dozen lines of code to fetch http://dev.i2p/i2p/i2pupdate.zip, verify it, then restart
14:20 < jrandom> ok, anyone else have anything to bring up for the meeting?
14:20 < ant> <cervantes> well I can already get the toolbar to download an update into the i2p folder AND trigger a graceful restart...but so far I haven't been able to get it verify the download's integrity
14:21 < jrandom> cervantes: ah, that part should be easy - at a later date, we'll have the update itself be self-verifying
14:21 < jrandom> (aka signed, verified by the router before installation)
14:21 < ant> <cervantes> jrandom: that would be cool.
14:21 < ant> <jnymo> ooh
14:22 < ant> <cervantes> perhaps it will be enough then that I trigger the download and then pop a "do you wish to restart" yes/no requester
14:22 < ant> <cervantes> so someone can verify manually if desired
14:23 < ant> <cervantes> (it already displays what the sha1 _should_ be)
14:23 < jrandom> hehe
14:23 < ant> <jnymo> how bout, "click here to autodownload on availability"
14:25 < cervantes> I'd rather avoid auto downloads
14:25 < ant> <jnymo> hmf.. microsoft does it ;)
14:26 < cervantes> but by all means alert the user that a download exists and offer a "download now" button
14:26 < jrandom> right, 1 click at the least. we can automatically /notify/ on update availability, but autoinstall is not ok
14:26 < jrandom> (er, what cervantes said)
14:27 < ant> <jnymo> now, how do 10000 people update? how bout integrating i2p-bt at one point?
14:27 < jrandom> yes, and flying ponies
14:28 < ant> <jnymo> good enough for me
14:29 < jrandom> ok cool... if there's nothing else...
14:29 <+postman> damn missed the meeting :/
14:29 * cervantes gets back to coding his vapourware
14:29 < jrandom> heh you're at the buzzer, in case there's something you want to bring up postman :)
14:30 <+postman> no thanks
14:30 <+polecat> Microsoft? =) I have gentoo doing it.
14:30 * jrandom winds up
14:30 <+postman> ooops
14:30 * jrandom *baf*s the meeting closed