I2P dev meeting, February 10, 2009 @ 21:00 UTC
altGuest, badger, dream, eche|on, hottuna_, l00kns33, unixfr3ak, welt, welterde, zzz,
Journal IRC complet
20:58:32 <unixfr3ak> dev meeting eh? 20:59:27 -*- dream turns on devo 21:00:25 <welt> dream: ah.. glad you're here too :) 21:00:51 <badger> 0) Hello 21:00:55 <dream> you are? 21:00:58 <badger> 1) I2P 0.7 21:01:02 <badger> 2) Syndie 21:01:06 <badger> 3) Donations 21:01:15 <badger> 4) ???? 21:01:21 <badger> 5) A short poem recital by zzz 21:01:39 <badger> 0) Hello 21:01:53 <altGuest> hi 21:02:00 <badger> welcome all to the #207th dev meeting 21:02:05 <badger> 'lo 21:02:20 <hottuna_> 'lo! 21:02:40 <eche|on> welcome! 21:02:43 <zzz> so, let's start by covering what's happened since April 10 2007, if anything 21:02:48 <badger> Just to put that in perspective it's been nearly 2 years since hte last one 21:03:06 <badger> well... bush is out....obama in.... 21:03:36 <dream> lol USA 21:03:51 <badger> 1) I2P 0.7 21:03:56 <eche|on> I guess the 0.7 release note is a good idea what happend to I2P 21:04:20 <badger> Well it looks like the rollout of 0.7 has gone fairly smoothly 21:04:22 <badger> with about 84% network coverage now 21:04:29 <unixfr3ak> not bad 21:04:48 <eche|on> :-) 21:04:48 <hottuna_> How much ahs the network grown since 0.7? 21:04:48 <badger> A big cheer to the dev team and release crew for getting it out of the door 21:04:52 <unixfr3ak> one bug i may point out that i and another user have noticed though is 21:04:52 <hottuna_> or even since Christmas? 21:05:21 -*- welt waits for stats.i2p to load.. 21:05:28 -=- Sie sind nun als welterde bekannt 21:05:31 <badger> hottuna_: a fairly slow but steady growth if the stats are anything to go by 21:05:41 <unixfr3ak> adding new private hosts in susidns requirs manual editing of the privathosts.txt file 21:06:08 <welterde> zzz: wasn't that the bug you fixed recently? 21:06:18 <welterde> or was that sth different? 21:06:25 <eche|on> the stats shows a steady slow growing 21:06:35 <zzz> yeah, i broke it in 0.7, just fixed it yesterday, will be in -4 21:06:40 <eche|on> welterde: yes, he seens to have fixed it 21:07:05 <badger> something to look forward to in 7.0.1 21:07:14 <welterde> zzz: good.. that's done then 21:07:16 <badger> eerm 0.7.1 21:07:19 <eche|on> more users :-) 21:07:22 <zzz> sorry about that 21:07:35 <unixfr3ak> what are you guys going to do about network lag...its a growing problem it seems , on the weekends i2p seems overloaded 21:07:56 <welterde> maybe some more streaming lib tweaks? 21:07:57 <unixfr3ak> ethier i think more users is good 21:08:00 <badger> zzz: well you've fixed and improved enough stuff to be allowed the odd breakage :) 21:08:33 <hottuna_> I've suggested motivating user to share by having some ratio indicator on the console 21:08:57 <unixfr3ak> that sounds good 21:09:14 <eche|on> network load went big last month 21:09:17 <zzz> freak, i'm looking at tweaking the capacity calculation in the peer profiles just a little, to react better when things get busy. 21:09:20 <eche|on> months, looks fairly well so far 21:09:51 <hottuna_> zzz: wicked :) 21:09:55 <unixfr3ak> this may be ambitious bout how about using a cron job in linux or whatever windows uses to volunteer bandwidth to i2p when their computer is not being used 21:10:17 <zzz> these things have to be adjusted with great care though, and it takes a full release cycle to test any change 21:10:21 <hottuna_> a scheduler would be and awesome solution aswell 21:10:24 <unixfr3ak> to dumb it down 21:10:28 <badger> The publicity push for release 0.7 seems to have had a marginal effect on numbers, but not nearly the impact I would have hoped for 21:10:41 <unixfr3ak> detect when network / cpu is idle and use it/ dont use when it is 21:10:43 <welterde> zzz: that recent addition to I2CP doesn't allow that yet, right? 21:10:52 <badger> some good coverage in german news sites though 21:11:04 <badger> but slashdot/digg/reddit was rather pathetic 21:11:09 <zzz> allow what welterde ? 21:11:29 <welterde> zzz: to change the ratio/up-bw/down-bw from outside the routerconsole 21:11:29 <eche|on> badger: it needs some time for users to get known to it and keep steady with it :-) 21:11:32 <unixfr3ak> and a defult auto startup registry entry would be nice or a simple shell script for unix 21:12:04 <zzz> no welterde it has nothing to do with that 21:12:08 <hottuna_> dunno about the pr.. i suppose that our 'brand name' will grow every time we have a new release adn a pr wave to that 21:12:13 <welterde> zzz: thought so :/ 21:12:56 <zzz> hopefully the gulli interview w/ me will be published soon, but I haven't heard from him in a week 21:13:06 <unixfr3ak> is i2p ready to ask for volunteer bandwidth from sponsors? (other than me with my tiny connection) 21:13:39 <welterde> hmm.. that might be worth a try 21:13:50 <dream> I don't think anyone has ever said no to volunteered bandwidth. 21:14:12 <unixfr3ak> the tor network has a lot of sponsored nodes, but on the other hand a lot of nodes on the same subnet would be suspicious to users and offer someone more control over the network 21:14:37 <welterde> i think we "fixed" that already 21:14:59 <hottuna_> sponsoring would'nt be a bad idea 21:14:59 <hottuna_> jas a simple html tab on the mainpage? 21:14:59 <hottuna_> just* 21:15:05 <unixfr3ak> randomly placed nodes by individual volunteers seems to be safer 21:15:05 <unixfr3ak> but not as practical 21:15:15 <unixfr3ak> most people by nature will leech 21:15:44 <dream> I don't think that's necessarily true unixfr3ak, but it's good to prepare for non-participants. 21:16:21 <unixfr3ak> for example 21:16:40 <unixfr3ak> someone who just starts the i2p router, and has no idea what it does and runs i2phex 21:16:49 <unixfr3ak> constantly downloading 21:17:11 <unixfr3ak> mabye the defualt bandwith should be changed 21:17:22 <hottuna_> has been changed in 0.7 21:17:34 <unixfr3ak> or users should be asked for connection speed during the install for more accurate bandwith shareing limits 21:18:26 <unixfr3ak> or mabye a virus that installs i2p as a backdoor :P 21:18:34 <welterde> heh 21:18:40 <hottuna_> would be a great idea.. the installer should support that, right? 21:19:08 <welterde> the first or the second? :> 21:19:08 <unixfr3ak> my joke or asking the connection bandwith? 21:19:23 <welterde> first) probably yes 21:19:26 <unixfr3ak> it should be a line or 2 in a config file somewhere 21:19:39 <unixfr3ak> the one without the :P 21:20:59 <badger> download limits for users who don't share upstream bandwidth? 21:21:15 <unixfr3ak> sounds intresting 21:21:20 <unixfr3ak> but 21:21:33 <unixfr3ak> i dont think we should go to such desprate measures yet... 21:21:38 <dream> by default it shares up to 100% of the bandwidth unixfr3ak. once it gets a few client tunnels, the majority is spent on intermediate ones. 21:21:45 <welterde> don't routers already punish other routers, who don't route tunnels? 21:22:00 <unixfr3ak> yes 21:22:00 <dream> and I think i2p is already load balanced. I sure cannot download more than I upload on the bandwidth tab. 21:22:25 <unixfr3ak> i think so but, if many people leech at one time it will still put a hevy load on the network 21:22:32 <badger> perhaps this is just a case of being more informative to first time users 21:22:35 <unixfr3ak> especially if thier ips are dynamic 21:22:46 <eche|on> http://stats.i2p/cgi-bin/tot.cgi?a=bandwidthReceiveBps.5m&s=365&u=y 21:22:56 <badger> make it clear that giving back to the network improves your experience 21:23:07 <unixfr3ak> yes 21:23:18 <unixfr3ak> and to run it when they are not using thier pc 21:23:36 <unixfr3ak> insted of just letting thier connection that they are paying for be idle 21:23:51 <dream> most people turn their computers off, it's really sad 21:24:09 <unixfr3ak> yes 21:24:12 <dream> paying their ISP per month, when they could instead for the price of 4 light bulbs... 21:24:15 <l00kns33> i think most people understand this - i even think most people who use i2p are geeks themself ;) 21:24:32 <badger> anyway moving on - anything else to add for 1) I2P 0.7? 21:24:55 <unixfr3ak> for now yes 21:25:16 -*- welterde waits for his signal.. 21:25:20 <unixfr3ak> but that may change in the future 21:25:25 <eche|on> badger: no 21:25:25 <badger> 2) Syndie 21:25:37 <welterde> ok then :) 21:25:37 -*- badger passes the 70s boom mike over to welterde 21:25:45 <badger> *mic 21:26:15 <welterde> as you may (or may not) i recently finished the effort to apply these patches from MOSFET 21:26:20 <welterde> +know 21:26:35 <unixfr3ak> leave e out on the forums i don't use them :P , brb cigarette 21:27:14 <welterde> which should fix some bugs and disable that (imho) b0rked default ui 21:27:26 <welterde> instead the swt one is used, which most users find easier 21:27:42 <badger> <jrandom>w0rd</jrandom> 21:28:11 <welterde> hmm? 21:28:30 <dream> it's nice to hear someone was working on getting failed synchronizations to retry. 21:28:40 <badger> welterde: sorry, old dev meeting joke 21:28:59 <badger> is there a new public syndie archive somwhere? 21:29:06 <welterde> anyway.. i hope i have time soon to replace that b0rked ;) index thingy 21:29:09 <welterde> badger: yup 21:29:25 <welterde> http://syndie.welterde.(i2p|de)/ 21:29:52 <dream> making it possible to run syndie using a remote database is important I'd say, to make it easier for people to run their own archives. 21:29:54 <welterde> but you can't post there (yet) as it is just a static archive 21:30:47 <welterde> have to that one to the default ones too 21:30:56 <welterde> will do that soonish 21:31:16 <eche|on> so syndie work goes on 21:31:32 <welterde> yup 21:31:54 <welterde> currently trying to profile syndie.. 21:32:29 <welterde> but wasn't able to spend much time in that area though.. 21:32:59 <eche|on> so much work to do... 21:33:14 <welterde> yes :/ 21:33:17 <dream> running syndie in text mode is tricky, since the interface seems to be slipping behind its current behavior 21:33:17 <dream> usually it works if you just leave it in --cli, but when it freezes there's no real indication. 21:33:41 <welterde> yeah.. the cli is b0rked too currently :/ 21:34:00 <welterde> imho we should seperate syndie into multiple parts, eg. libsyndie, gui, cli, ... 21:34:12 <badger> makes sense to me 21:34:19 <welterde> that should make writing custom extensions, etc. easier 21:34:29 <dream> What sort of stuff would libsyndie cover? 21:34:36 <badger> early v0.0.1 syndie's UI was just a top on the cli binary 21:34:48 <badger> but it seems that idea got lost enroute 21:34:55 <dream> it even has the text console today. 21:35:23 <welterde> dream: message decoding, archive syncing, etc. etc. 21:35:34 <welterde> most of the logic 21:36:06 <dream> so libsyndie is pretty much an interface over the database, and maybe the archive/ directory? 21:36:09 <badger> aye, gui, cli and webtop should just be a light wrapper 21:36:10 <welterde> imho we should keep gui/cli seperate from the program logic 21:36:42 <welterde> dream: the archive isn't used to store anything.. it's just used for serving the archive 21:37:02 <dream> I know that. 21:37:14 <welterde> but as cli/webtop use it we should put it into the libsyndie as well 21:37:15 <dream> So I guess only the web server would need to deal with that directory. 21:37:35 <dream> filling it and synching from it, sort of like a postfix mail queue. 21:38:00 <welterde> but we should only generate/sync it, when we are actually using it.. not like now.. 21:38:08 <welterde> where it is always generated/synced... 21:39:18 <dream> I don't see a problem with only using the archive/ directory for the webserver. It's really just a convenience so you can use existing static file serving functionality. 21:40:07 <welterde> there should be a cli command like generate_archive or something like that imho 21:40:57 <welterde> and we should bring that import.cgi back, so we can run a mostly static archive, while still being able to post 21:41:04 <welterde> or... hmmm... 21:41:04 <dream> what would you do with that archive using the client interface? 21:41:15 <welterde> rsync with a remote site? 21:41:26 <welterde> that's how syndie.welterde.(i2p|de) works ;) 21:41:43 <dream> trouble with a static archive is that keeping the filesystem up to date with the database is a task that is similar to designing a database. 21:41:59 <welterde> hmm.. not really 21:42:05 <welterde> as it's one-way only 21:43:17 <unixfr3ak> this may be a little off-topic but has anyone considered a datastore function? 21:43:20 <dream> so using a hypothetical --cli someone creates a message. They then generate_archive after creating it? Sounds suspiciously similar to commiting a transaction after inserting. 21:43:52 <unixfr3ak> also in i2phex as i told Complication previously the bitzi lookup in i2phex inst anonymous 21:43:55 <dream> magicbutton() 21:44:04 <welterde> dream: uhm.. no 21:44:17 <dream> ...i2phex checks bitzi.com? that's nuts 21:44:37 <unixfr3ak> yes 21:44:39 <welterde> unixfr3ak: there was some work in direction of freenet afair 21:44:43 <dream> welterde, so then their message never goes into the archive/ directory and can't get synchronized... 21:45:20 <welterde> dream: no.. just mean that a transaction is a bit different 21:45:27 <welterde> for example: you don't edit anything 21:45:33 <welterde> (except for the index maybe) 21:46:02 <welterde> generate_archive just dumps the db and updates the indexes while doing that 21:46:41 <unixfr3ak> right click a file 21:47:20 <unixfr3ak> and view bitzi ticket takes you to the non-anon site 21:47:20 <unixfr3ak> lucky my browser is proxyd by i2p, and my alternate one tor 21:47:31 <dream> so how do you get your new database content into the archive? What if syndie dies after inserting a message, but before you save it to the archive/ directory? 21:47:39 <unixfr3ak> 0_0 looks like spongebob missed the meeting 21:47:57 <welterde> dream: nothing.. it's just not archive/ 21:48:16 <welterde> but it will be on the next successful run of generate_archive 21:49:01 <dream> what I'd do is let the client run the web server, and the web server checks archive/ and pulls out all the messages in the db not already there. Or just serve the db messages directly. 21:49:23 <dream> generate_archive doesn't seem like the sort of thing you'd want the client to have to keep track of. 21:49:50 <welterde> problem is.. you can't run syndie on every machine 21:50:18 <welterde> for example this server (i2p2.de/welterde.de) has reached it's limited 21:50:36 <welterde> it will heavily swap when i run syndie on it.. 21:50:41 <welterde> so i have to run it locally 21:50:46 <eche|on> yeah 21:51:06 <welterde> no problem if i had reasonable upload... which i don't have 21:51:19 <welterde> which most adsl-users don't have.. 21:51:45 <badger> anyway - good work with the all the patches welterde - can we expect a release in the not-too-distant-future? 21:51:47 <welterde> so it's either a static archive or one that is slow as hell 21:52:08 <welterde> badger: i think i'll switch from a to b (alpha to beta) soonish 21:52:16 <badger> great 21:52:40 <badger> anything else to add about future dev? 21:52:56 <badger> (syndie) 21:53:10 <welterde> n0pe 21:53:19 <welterde> ;) 21:53:24 <badger> righty in that case 21:53:30 <badger> 3) Donations 21:53:49 -*- badger swings the mic over to eche|on 21:54:00 <eche|on> it's open again! 21:54:18 <eche|on> I created a paypal account and linked it on i2p website 21:54:42 <hottuna_> :D 21:54:47 <badger> coolio 21:54:50 <hottuna_> wicked 21:54:52 <eche|on> but the buttons links to https:// sites of paypal, works not for eepsite yet 21:55:01 <dream> yeah I guess that's an advantage welterde 21:55:08 <eche|on> til yet no entry on that front 21:55:20 <welterde> eche|on: maybe you should add some notes on how to tell you what you should do with it 21:55:29 <eche|on> and undecided about a acc for 2ndlive 21:55:31 <zzz> can you add a link from the donate page to the halloffame page, and/or provide more info on what donations will be used for 21:55:39 <dream> I still think whatever creates the archive should synchronize more than just dump. 21:55:48 <badger> yup 21:56:02 <badger> are you planning to support bounties too? 21:56:10 <eche|on> welterde: acked 21:56:13 <unixfr3ak> you could just use apache 21:56:17 <welterde> dream: premature optimization ;) 21:56:19 <eche|on> zzz: acked 21:56:24 <dream> oops 3) 21:56:24 <dream> I don't have any money sorry T_T 21:56:28 <eche|on> we need a list of stuff to buy/not to buy with donations 21:56:37 <zzz> and shouldnt echelon and welterde subscriptions really be listed as expenses instead? 21:56:40 <unixfr3ak> what web server does i2p include? 21:56:51 <eche|on> badger: yeah, donations are "for all funds" or dedicated for a bounty 21:57:04 <badger> grand 21:57:19 <eche|on> and in paypal there should be a textfield in which you can enter the goal of the money :-) 21:57:33 <zzz> you could also put a news link on the front page that donations are open 21:57:36 <badger> If I donate 1000 EUR do I get a Hot Tuna i2P t-shirt? 21:57:51 <eche|on> but I cannot donate to myself ;-) 21:58:02 <welterde> hottuna_: say yes! ;) 21:58:16 <eche|on> no prob so far, I wait for the first one and announce it ;-) 21:58:35 <zzz> you had your chance to come to 25c3 and get a shirt 21:58:47 <welterde> there is still a 26c3 ;) 21:58:59 <eche|on> acked, zzz - nice idea 22:00:32 <eche|on> so no more from my site to topic donations 22:00:51 -*- welterde waits for paste to load.. 22:01:16 <badger> in that case: 22:01:22 <badger> 4) ???? 22:01:33 <badger> anyone else have anything to bring to the meeting? 22:01:37 <welterde> yup.. 22:01:46 <welterde> but you have to wait until paste loads :/ 22:01:52 <eche|on> lets have a piece of cake for everyone! 22:02:31 <welterde> yay! :) 22:02:32 -*- unixfr3ak takes it and runs 22:02:38 <welterde> nooooo 22:03:03 -*- badger *bafs* unifr3ak on the head 22:03:08 <unixfr3ak> yessss 22:03:12 <eche|on> ;-) 22:03:46 <unixfr3ak> i wonder if that part will go in the meting log 22:03:50 <unixfr3ak> :P 22:03:57 <welterde> I hereby announce *drum roll* thmoo: inbljam6y6mynwz2474hk655w2jtv7trofxbqzng4re26ga6rg4a.b32.i2p 22:03:58 <welterde> ;) 22:04:04 <welterde> unixfr3ak: of course it will! 22:04:15 <welterde> everyone get a telnet client and connect ;) 22:04:37 <badger> not a MUD?! 22:04:40 <unixfr3ak> the base 32 key? 22:04:49 <welterde> badger: of course! 22:05:06 <welterde> unixfr3ak: you have to open a client tunnel and connect to that with a telnet/mud client 22:05:08 <welterde> (or use socks) 22:05:38 <unixfr3ak> i dont want to get my socks dirty ill make a tunnel :p 22:05:43 <unixfr3ak> hmm 22:05:47 <unixfr3ak> but for destination 22:05:50 <badger> muddy socks 22:05:59 <unixfr3ak> does that include the .i2p ? 22:06:05 <welterde> unixfr3ak: yup 22:06:11 <welterde> worked for me at least ;) 22:06:56 <dream> you can also look up the dest of a b32 if you want a local copy. zzz showed me how using i2ptunnel's secret cli interface. 22:07:13 <unixfr3ak> Delay Connect: (for request/response connections) 22:07:18 <unixfr3ak> i take it yes for that 22:07:21 <dream> that reminds me I should get these room descriptions off paper and into the darn thing 22:07:24 <badger> welterde: maybe post a short howto somewhere ;-) 22:07:35 <welterde> dream: yay :) 22:07:46 <welterde> badger: heh.. will do 22:07:58 <unixfr3ak> Trying 127.0.0.1... 22:07:58 <unixfr3ak> Connected to localhost. 22:07:58 <unixfr3ak> Escape character is '^]'. 22:08:02 <unixfr3ak> impressive :P 22:08:02 <welterde> http://paste.i2p2.i2p/show/11/ <- the b64 22:08:08 <l00kns33> one comment about i2p in general: 22:08:08 <l00kns33> i think it is too much "from geeks for geeks" - you need to know what non-geek users need and want 22:08:16 <unixfr3ak> wonder whats on the other side of the tunnel 22:08:20 <dream> unixfr3ak, if you're extra paranoid yes, otherwise timing attacks may be possible to test if you're online or not. :> 22:08:21 <welterde> l00kns33: they want games! :D 22:08:46 <dream> l00kns33, what could be less geeky than a text based online adventure game! 22:09:01 <welterde> unixfr3ak: works? you should see a menu of some kind 22:09:02 <dream> I put on my robe and wizard hat! 22:09:19 <unixfr3ak> of coarse 22:09:28 <l00kns33> that's one thing - and a good idea :) 22:09:31 <unixfr3ak> Welcome to thmoo-cmd 2.1... 22:09:38 <welterde> ha :) 22:09:47 <welterde> you then need to type connect guest afair 22:09:52 <unixfr3ak> whats so impressive about telnet over i2p? 22:10:30 <zzz> we'll have a connect client soon so you won't need to set up a tunnel 22:10:46 <l00kns33> cool :) 22:10:50 <welterde> unixfr3ak: nothing? 22:11:20 -*- welterde writes up a howto.. 22:11:26 <unixfr3ak> has a weird chat feature :P 22:11:45 <badger> well on that note - anything else anyone wants to add? 22:11:46 <welterde> unixfr3ak: you have to "say something" 22:11:50 <dream> I wonder how that would work zzz? You mean like a VPN? 22:12:01 <welterde> dream: more like socks i think 22:12:05 <dream> Or a specially designed telnet client? ._. 22:12:19 <dream> Oh well I did hear about SOCKs. 22:12:29 <unixfr3ak> foo siad hi 22:12:31 <zzz> more like socks 22:12:39 <zzz> telnet localhost 1234 22:13:00 <zzz> connect inbljam6y6mynwz2474hk655w2jtv7trofxbqzng4re26ga6rg4a.b32.i2p 22:13:00 <welterde> unixfr3ak: and to answer you to "say something" ;) 22:13:06 <zzz> thats it 22:13:15 <dream> socks is tricky, since it's like i2ptunnel except just about anyone can make new tunnels to different places. 22:13:37 <unixfr3ak> yes i know...no need to point out the painfully obvious 22:13:50 <welterde> dream: no.. i just uses the shared one 22:14:06 <welterde> at least.. that's how it should work ;) 22:14:34 <welterde> afk for a bit 22:14:36 <badger> well I think we've reached a good point to... 22:14:44 -*- badger winds up 22:14:54 -*- badger *baf*s the meeting closed 22:15:10 <eche|on> :-) 22:15:13 <badger> good job everyone 22:16:12 <dream> you can't make a server tunnel with the SOCKS thing? hmm... 22:16:34 <dream> I guess that would be a pretty nice thing for non HTTP protocols. :) 22:16:49 <dream> Either that or implementing CONNECT in the eeproxy. 22:16:52 <unixfr3ak> now you guys are going to dissapear again lol 22:18:38 <dream> poofda 22:19:40 <zzz> I'm still here 22:19:49 <zzz> our socks is client-only now 22:20:51 <zzz> I have CONNECT implemented, that's what I was talking about above 22:23:20 <dream> Neat I can't think of any reason why not to do that, and it'd be lots more convenient since SOCKS is so goddamn popular many apps come with it.