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: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: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?
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.
