I2P dev meeting, January 11, 2005

Quick recap

  • Present:

cervantes, deer, dm, duck, fdr, jrandom, lucky, protok0l, toad_,

Full IRC Log

13:10 < jrandom> 0) hi
13:10 < deer> <Ragnarok> you're fired
13:10 < jrandom> 1) Net status
13:10 < jrandom> 2) 0.5 progress
13:10 < jrandom> 3) 0.6 status
13:10 < deer> <polecat> bye!
13:10 < jrandom> 4) azneti2p
13:10 < jrandom> 5) fbsd
13:10 < jrandom> 6) hosts.txt as WoT
13:11 < jrandom> 7) ???
13:11 < jrandom> 0) hi
13:11  * jrandom waves
13:11 < fdr> yo
13:11 < deer> <Ragnarok> hola
13:11 < toad_> you just starting? /me will just watch from time to time
13:11 < deer> <detonate> hi
13:11 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2005-January/000551.html
13:11 < jrandom> cool, all are welcome
13:11 < deer> <polecat> Oh.  Not your employment.  My bad.  =3
13:11 < jrandom> the logs of the dev meetings are posted up @ the website (after the meeting, of course)
13:11 < fdr> I'm starving, so I'll be in and out..
13:12 < jrandom> ok, swinging on int to 1) Net status
13:12 < jrandom> things seem to be working fine.  duck is back (yay!)
13:12 < jrandom> I dont really have much to add beyond whats in the email - anyone else have anything?
13:13 < deer> <jrandom> nope
13:13 < jrandom> ok, if not, moving on to 2) 0.5 status
13:14 < jrandom> There's been some good progress here, finally got the matrix encryption working, but after chatting with polecat the other day, theres a little tweak we need to add on
13:14 < toad_> talking to yourself?
13:14 < jrandom> heh yeah, until anyone replies ;)
13:14 < jrandom> (you should have seen these meetings before I posted the weekly status notes beforehand)
13:14 < toad_> I meant across networks. I talk to myself all the time, but not usually across networks. ;)
13:15 < deer> <jrandom_> across three networks even [iip here]
13:15 < deer> <Ragnarok> stop that, it's creepy :)
13:15 < deer> * postman waves
13:16 < jrandom> I dont really have anything else to add wrt 0.5, beyond "more info coming soon"
13:16 < deer> <polecat> Re net performance, my i2p router went down 24h ago, but before that I managed 8 days of uptime.
13:16 < jrandom> ah ok cool
13:16 < jrandom> OOMed?  were you running bt or just from activity?
13:17 < deer> <polecat> Just a heuristic to brag about.  =3
13:17 < deer> <frosk> i generally get as much uptime from my router as i want, although usually no more than 8-9 due to upgrades :)
13:17 < deer> <frosk> 8-9 days, that is
13:18  * jrandom wishes my kaffe box could do that (oh well)
13:18 < deer> * orion can crash a router at will by running 40+ local destinations via btlaunchmanycurses.py. ;)
13:18 < jrandom> heh yes, that would do it orion
13:18 < deer> <polecat> Oh, the logs say that the JVM appears hung, so I suppose lucky must have used me in a tunnel to download gigabytes of over endowed men.
13:18 < deer> <orion> but, I've had uptime of 15 days before BT storms.
13:18 < jrandom> oh interesting polecat.  
13:19 < jrandom> polecat: if you're feeling brave, it might be worth trying the latest java service wrapper
13:19 < jrandom> (if it gets rid of that we should upgrade)
13:19 < deer> * laberhorst had uptime 15days with 0.4.2.5 without bt
13:19 < jrandom> i think cervantes is still the winner w/ 0.4.1.1 @ 41 days
13:20 < deer> <polecat> Anyone want to PM me on how to get the latest java service wrapper?
13:20 < jrandom> but anyway, anyone have any comments on 0.5 stuff?
13:20 < protok0l> is i2p done yet?
13:20 < jrandom> http://wrapper.tanukisoftware.org/doc/english/
13:20 < deer> <eco> looking forward to the docs
13:20 < jrandom> !thwap protok0l 
13:21 < jrandom> ok, moving on to 3) 0.6 status
13:21 < deer> <polecat> I still think that there ought to be a way to checksum without the gateway knowing all the checksums, or how many.
13:21 < deer> <Ragnarok> where are the documents going up?
13:21 < jrandom> polecat: I'd love it, but I doubt it can be done.  
13:22 < jrandom> Ragnarok: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel.html?rev=HEAD is the current draft
13:22 < jrandom> (not updated wrt the first hop issue)
13:22 < deer> <Ragnarok> thanks
13:22 < deer> <polecat> "They said it couldn't be done.... they called me mad... but they were fools, FOOLS!
13:22 < jrandom> heh
13:22 < jrandom> hey, if you can find a way, I'm all ears
13:23 < jrandom> (and I have a feeling the mixmaster/mixminion folks will be too)
13:23 < deer> <jrandom> zounds, 42 usres here
13:23 < deer> <jrandom> mule: you 'round?
13:24 < deer> <polecat> Heh.  Will keep my nose to the ground then, but no promises as I'm just a dumb ferret not geniushes like y'all.
13:24  * jrandom flings a small furry animal at polecat
13:25 -!- dm [mihi@dsl-80-42-80-26.access.uk.tiscali.com] has joined #i2p
13:25 < jrandom> ok, anyway, 0.6 stuff looks interesting, and mule has started on some hacking, but its still early on in the game
13:26 < jrandom> zab has been pretty helpful giving us some guidance from how limewire goes about things, but, well, their congestion control is kind of scary (fixed small windows, full ack)
13:26 < jrandom> (but i'm sure they'll improve in time, of course)
13:26 < jrandom> also was nice of him to give us a view into how they're having the rubber hit the road, what gotchas they've had with various jvms, etc
13:27 < jrandom> (yay zab)
13:27 < jrandom> in any case, if you're interested in helping out with the design and implementation or integration of some other provider for 0.6, get in touch with either mule or myself (or, of course, send patches ;)
13:28 < jrandom> not much else to say on that, unless anyone has anything to bring up?
13:28 < deer> <polecat> Isn't 0.6 supposed to have preliminary fusenet support?
13:28 < deer> <frosk> by april, hopefully :)
13:29 < toad_> fusenet?
13:29 < deer> <frosk> but with all this work on the udp transport, maybe it'll be ready before fusenet will
13:29 < jrandom> yeah, the general aim is just to get the ball rolling
13:29 < deer> <frosk> fusenet is a content-distribution system more or less like usenet on speed
13:29 < toad_> cool
13:30 < deer> <frosk> it will initially support blogs, discussion forums and addressbooks for i2p name-destination mappings
13:30 < jrandom> though of course, if we get the UDP transport implemented next month, we'll probably roll that out with 0.5
13:31 < deer> <frosk> of course, that would be cool :)
13:31 < jrandom> and if i had a pony, i'd play with him aaaaalll day
13:31 < jrandom> ok, thats prolly 'bout it for 0.6 stuff, moving on to 4) azneti2p
13:31 < deer> <frosk> i'm glad you have no pony, then ;)
13:31 < jrandom> heh
13:32 < jrandom> azneti2p == kickass.  
13:32 < jrandom> parg & the rest of the azureus folks have done some great work, and the integration is really nice
13:33 < jrandom> torrents work the same as before, show up with all the pretty graphs, lets you do all the queueing / etc you're used to in azureus, except anonymously
13:33 < deer> <postman> w00t!
13:33 < jrandom> there are still further optimizations and simplifications left to do, but all in all, i'm quite impressed
13:33 < deer> <eco> hurray! enter the masses...
13:33 < deer> <frosk> i understand you still have to do some manual labour in the router console before you can use it?
13:33  * jrandom holds the gates closed for just a litttttle wile longer
13:33 < deer> <eco> is java 1.5 indeed required?
13:34 < deer> <polecat> Yup.. neat stuff except you can't leave it to daemon out.
13:34 < deer> <postman> sounds like the invitated for the i2p network to get his ass kicked badly
13:34 < jrandom> frosk: right - but we're working on patching it up to do the I2PTunnel calls within the plugin itself
13:34 < deer> <frosk> cool
13:34 < jrandom> eco: unsure, I only tried it with 1.5, but I believe them when they say it.  
13:34 < deer> <polecat> eco: I should hope not.  o.O  1.5 is just Sun trying to strongarm the market.
13:34 < jrandom> worth trying though, i'll do so later
13:35 < deer> * postman does not care, i got gigabit ethernet interfaces and LOTS of traffic included :)
13:35 < deer> <polecat> Oh dear... and azareus requires it.  I _really_ have to make my C++ torrent app.
13:35 < jrandom> polecat: azureus does have a headless mode of operation, and a web console
13:36 < deer> * polecat blinks.
13:36 < jrandom> (but its... tough to the uninitiated [like myself])
13:36 < deer> <polecat> Well okay then... I thought it didn't, like KazAa
13:36 < jrandom> but i only glanced at it (and ran back to the GUI ;)
13:36 < deer> <Ragnarok> is duck going to be bringing i2p-bt up to 3.9/4.0?
13:37 < jrandom> ragnarok: unknown, but duck is currently doing leaps and bounds to keep all the existing stuff compatible with azneti2p
13:37 < jrandom> (they had to do some... odd changes due to technical requirements)
13:37 < deer> <polecat> One of the most powerful aspects of p2p is if the app can run quietly in the background whet you're not using it.
13:38  * jrandom isnt arguing with that point
13:38 < jrandom> ok, i think thats all i have to say wrt azneti2p (other than w00t, again).  more info in the email, and there'll be lots of activity in #i2p-bt i'm sure
13:39 < jrandom> anyone else have anything to bring up wrt azneti2p?
13:39 < cervantes> are you ready for it... ;-)
13:40 < jrandom> heh, we're workin' on it
13:40 < deer> <polecat> Might I note that the source of azareus is totally abysmal...
13:40 < deer> <polecat> There are 28 main entry points, and it uses at least a namespace depth of 3.
13:40 < deer> <Ragnarok> does any bt client have nice source?
13:40 < jrandom> there are some oddities, but i suspect you'll find that in anyone else's source (NIH)
13:40 < deer> <polecat> Mine will.
13:40 < jrandom> oh c'mon, net.i2p.router.netdb.kademlia.* :)
13:41 < deer> <Ragnarok> not if it's in C++ it won't :)
13:41 < toad_> lol
13:41 < deer> <polecat> I said at least!
13:42 < jrandom> ok, anyway, moving us along to 5) fbsd
13:42 < deer> <polecat> Ragnarok: You've never seen how I *cough*rape*cough* use C++.  n.n
13:42  * duck looks in
13:42 < deer> <polecat> Who cares about FreeBSD?  Show of hands?
13:42 < jrandom> lioux has packaged up the 0.4.2.6 release into ports (w00t!)
13:42 < deer> * detonate raises his
13:42 < deer> <polecat> Paws, tentacles, wings, etc?
13:43  * jrandom raises my hand
13:43  * [dave] raises
13:43 < deer> <Ragnarok> duck: 3.9/4.0? :)
13:43 < deer> <polecat> Woah, i2p is integrated into a distribution?
13:43 < duck> Ragnarok: the lack of comments / docs / etc on the latest bram-Bittorrent changes were a bit of a setback
13:43 < fdr> FreeBSD is cool :(
13:43 < deer> <Ragnarok> I'll bet
13:43 < fdr> I may be biased though.
13:44 < jrandom> aye, i was worried at first polecat, but his ports impl looked really really easy (so updates will be really really easy)
13:44 < duck> It would require studying what they did, maybe it would be worth the effort
13:44 < deer> <polecat> As far as I'm concerned, fbsd is a distro with an odd kernel and lots of data hiding.  It's all POSIX in the end so... ;)
13:44 < jrandom> polecat: and very, very w0nky JVMs
13:45 < duck> though secretly I have been hoping on azneti2p solving all problems
13:45 < deer> <Ragnarok> duck: it did sound like there were some nice improvements, but you're the one who'd probably be doing the work, so... :)
13:45 < deer> <polecat> Ugh... don't remind me.
13:45 < jrandom> heh, azneti2p will probably fit the needs of many users, but simple CLI tools will still make sense for the ubergeeks out there
13:46 < jrandom> anyway, so it seems he's tested i2p 0.4.2.6 on fbsd5.3 without problems (w00t)
13:46 < deer> <Ragnarok> oy, I don't like azureus, I'd much rather use the normal client
13:46  * jrandom has only done so on 4.8
13:46 < duck> currently I'd like to do something with kenosis; being a hit-n-run coder
13:47 < deer> <eco> jrandom: what jvm did he use?
13:47 < jrandom> kenos2p
13:47 < jrandom> eco: native compiled sun 1.4
13:47 < jrandom> (booo hiss)
13:47 < deer> <eco> ah, illegal!
13:47 < deer> <polecat> Ragnarok: If you want to critique my bittorrent client design, my current code plan is here: http://polecat.i2p/bittorrent.plan.txt
13:47 < jrandom> ((but kaffe works))
13:48 < jrandom> eco: is it illegal?  I thought you could agree to the terms and get the source legit on fbsd
13:48 < deer> <eco> sun withdrew the license afaik
13:48 < jrandom> hmm, i think thats just the blackdown license
13:48 < jrandom> (and, tbh, blackdown sucks)
13:49 < jrandom> individuals can still license it under SCSL
13:49 < deer> <polecat> ouch.
13:49 < jrandom> (first born child, etc)
13:49 < jrandom> heh, its interesting to hear such license gripes when so few have copyright gripes ;)
13:50 < jrandom> but this discussion is best for the 7) ??
13:50 < jrandom> and we're on 5) fbsd
13:50 < deer> <eco> license stuff on http://www.freebsdfoundation.org/press/20041221-newsletter.shtml , but back to the main thread...
13:50 < cervantes> first time we've crept above 5) in a long time
13:51 < jrandom> cervantes: and we had to trim things ;)
13:51 < jrandom> ok, i think thats it for fbsd stuff (beyond yay!)
13:51 < jrandom> so jumping into a messy one... 6) hosts.txt as a WoT
13:51 < deer> <polecat> licensing can get you at the node though, whereas copyright vio can only be tracked to the destination.
13:51 < deer> <polecat> Which "can't" be found.
13:52 < jrandom> right right polecat, but once They have physical control of your box, you're in deep shit anyway
13:53 < jrandom> ok, anyway I'm not sure if there's much I have to add to what was posted in the email wrt hosts.txt
13:53 < jrandom> anyone have any questions/comments/concerns?
13:53 < jrandom> (was I vague enough?  :)
13:53 < duck> yes
13:53 < deer> * eco considers handing hosts.txt management over to the UN
13:54 < jrandom> heh yeah, because we know nice centralized beurocratic authorities always Do The Right Thing
13:54 < toad_> lol
13:55 < jrandom> i suppose the real "big win" will be when the addressbook gets both a web interface and more metadata
13:55 < jrandom> (and perhaps the fusenet syndication, etc)
13:55 < deer> <Ragnarok> metadata will be the next thing I work on, using xml name records
13:56 < jrandom> kickass ragnarok!
13:56 < jrandom> whats your take on the WoT side ragnarok - do you see it as an issue with the addressbook, or how you forsee naming?
13:57 < deer> <Ragnarok> Essentially I think the way addressbook works (and how passing around name references on fusenet will work) is the only really sensible way to handle naming on i2p
13:58 < deer> <Ragnarok> so, the WoT is a feature :)
13:58 < jrandom> Wo0T
13:58 < lucky> whoa
13:58 < deer> <eco> but surely you sell premium accounts?
13:58 < lucky> is that a toad i see?
13:58 < lucky> a real toad?
13:58 < lucky> or just a frog.
13:58 < deer> <frosk> the important point imho, is how to handle collisions
13:59 < toad_> a toad
13:59 < deer> <detonate> first come, first serve
13:59 < jrandom> right frosk, it'd be nice to have an interface to manage those, rather than just "read the log"
13:59 < deer> <Ragnarok> frosk: I think that's more an issue of interface than anything else.  Collisions will have to be resolved by the user.
13:59 < toad_> call my name if it gets close to my area :)
13:59 < deer> <frosk> Ragnarok: my thinking too
13:59 < deer> <Ragnarok> anything else can be attacked
13:59 < lucky> oh, not the freenet toad.
13:59 < lucky> oh
13:59 < lucky> it is.
13:59 < deer> <eco> so the names are simply like aliases in IM?
14:00 < deer> <frosk> collisions need to be stored so you can switch long after the fact
14:00 < deer> <Ragnarok> and is probably not provably better in the general case
14:00 < lucky> we're paying toad now?
14:00 < jrandom> eco: right - the names are just private local nicknames
14:00 < deer> <susi23> the addressbook should recognize collisions and notify the user so he can decide
14:01 < deer> <Ragnarok> frosk: after the switch to name records, the intent is to never throw them away, but make it easy to change the address they correspond to
14:01 < deer> <susi23> until the user made his decision any changes regarding the collision should somehow get "quarantined" :)
14:01 < deer> <Ragnarok> susi23: that's essentially how it works now
14:01 < deer> <Ragnarok> it just has a lousy interface
14:01 < deer> <frosk> Ragnarok: sounds good :) do you have a web interface in the works? (or is there one already i'm not aware about?)
14:02 < deer> <susi23> fine then
14:02 < deer> <Ragnarok> nope.  I don't do web interfaces :)
14:02 < deer> <Ragnarok> susi was working on something, I think, but I'm not sure what's happened with that
14:02 < jrandom> (volunteers?  any chance of reviving susidns to manage the names?)
14:03 < deer> <susi23> ok, give me a week, I put it on TODO
14:03 < jrandom> (and after susidns, we need susitorrent and susiirc...)
14:03 < jrandom> wikked!
14:04 < jrandom> ok, anyone have anything else to bring up wrt that whole hosts.txt thing?
14:05 < jrandom> if not, moving on to 7) ???
14:05 < deer> <Ragnarok> one thing
14:05 < jrandom> you've got the mic
14:05 < deer> <Ragnarok> for the next release, can we agree that hosts.txt should be managed directly by addressbook, so we can stop mangiling userhosts.txt?
14:06 < jrandom> sounds reasonable.  i'll stop shipping hosts.txt in the i2pupdate.zip (but will include it in i2pinstall.jar)
14:06 < deer> <Ragnarok> cool.  That's all :).
14:07 < jrandom> ok, now back to the opne floor
14:07 < jrandom> anyone else have anything they want to bring up?
14:07 < deer> <postman> yes
14:07 < jrandom> hit it postman
14:07 < deer> * postman raises his hand
14:08 < deer> * postman is desperately looking for a volunteer providing the secondary MX server for i2pmail.org ( this being an inproxy to the internal mailsystem )
14:09 < deer> <postman> if anyone got a stable, fast (dedicated) machine, i would be very happy to accept  help
14:09 < deer> <postman> configuration / howto will be delivered by me
14:09 < deer> <eco> how fast is fast?
14:10 < deer> <postman> eco: static IP wuld be nice - everything else is negotiable
14:10 < jrandom> how much traffic are you seeing through mail.i2p postman?
14:10 < jrandom> (external, that is)
14:10 < deer> <polecat> Stable, fast, dedicated... well 1/3 isn't bad.
14:10 < deer> <postman> the mailtraffic is VERY low
14:10 < deer> <postman> in/out is about 500 mails / month
14:11 < jrandom> ah cool
14:11 < deer> <Frooze> i have slow (500 MHz), stable, dedicated
14:11 < deer> <postman> BUT since the inproxy will have a I2P running
14:11 < jrandom> (that'll probably pick up as more people find out about it though ;)
14:11 < deer> <eco> the machine would be for incoming mail only?
14:11 < deer> <postman> most traffic would be I2p i guess
14:12 < deer> <postman> eco: at least incoming ( it's needed for this ) 
14:12 < deer> <postman> if the operator is ok with that i would like to rotate outgoing over both machines
14:12 < deer> <postman> Frooze: it's ok, when it's able to run i2p
14:13 < deer> <postman> just drop me a mail
14:13  * toad_ wonders if his current issues are AOB business or if they are simply between him and jrandom
14:13 < deer> <postman> if anyone is interested
14:14 < deer> * postman hands back the mike
14:14 < deer> <Frooze> will do.
14:14 < deer> <postman> thanks jr :)
14:14 < jrandom> cool, thanks postman
14:14 < jrandom> toad_: i think there's much to be discussed, though largely a question for the freenet folks
14:15 < toad_> jrandom: right
14:15 < toad_> jrandom: talk after meet
14:15 < jrandom> sounds good
14:15 < duck> no public mudfight? :/
14:15 < jrandom> ok, anyone else have anything to bring up for the meeting?
14:15 < jrandom> heh duck
14:15 < deer> * eco points at http://dodo.freenetproject.org/pipermail/tech/2005-January/001224.html
14:15 < jrandom> (that was on tehc ;)
14:15 < cervantes> postman: my box has too much shit running on it to be any help I'm afraid ;-)
14:15 < deer> <polecat> Ragnarok: If we could sign the addressbook host data, that would allow for automatic updates.  Otherwise not much to be done.  Even if the user gets a popup, how are they to tell which key is accurate?
14:15 < deer> <Ragnarok> what does accurate mean?
14:16 < jrandom> polecat: signing entries would Kick Fucking Ass.
14:16 < deer> <eco> fyi
14:16 < deer> <eco> no mud involved.
14:16 < deer> <Ragnarok> (and signing is planned for name records)
14:16 < deer> <postman> cervantes: hi, thanks anyway :)
14:16 < cervantes> you are indeed very welcome
14:16 < cervantes> :P
14:17 < jrandom> ok, anything else?
14:17 < deer> <polecat> Ragnarok: accurate means centered around the correct result.
14:17 < cervantes> polecat: I'm waiting for one of my clients to go bust before I sneak into one of their forgotten mailservers to install i2p
14:18 < deer> <Ragnarok> polecat: yes, but what's the correct result?
14:18 < jrandom> lol cervantes 
14:18 < cervantes> %s/polecat/postman
14:19 < deer> <polecat> The addressbook file that gets sent between eepsites could do the signing in its format, keeping the other hosts.txt the same.
14:19  * duck wonders if updating dot.png is useful?
14:19 < duck> it got kind of full
14:19 < deer> <eco> give us a 3d applet
14:20 < jrandom> duck: its a bit hard to read yeah ;)
14:20 < jrandom> duck: perhaps only list the blue lines?
14:20 < jrandom> to me, the value comes from seeing how spread out green is
14:20 < jrandom> (or whether there are clusters of dark green, etc)
14:20 < deer> <Ragnarok> polecat: signing will be supported in the xml name record format.
14:21 < deer> <polecat> Ragnarok: The correct result is that the human readable name maps to the destination you expect to see, and only changes when the owner of that destination changes keys.
14:21 < deer> <polecat> Right.  So... great.  No problem then.
14:21 < deer> <Ragnarok> polecat: that's what we've got now
14:22 < deer> <polecat> If the signature of an update matches the original record's public key then you can update automatically, no problem.
14:24 < jrandom> ok, there's still room left to be hashed out on the Great Naming Debate, of course
14:24 < jrandom> anyone have anything else for the meeting?
14:24 < deer> * eco has a UI poll
14:24  * jrandom has a GUI
14:25 < deer> <Ragnarok> polecat: that will be supported once we've got signing :)
14:25 < deer> <eco> the i2ptunnel option in the web ui results in a popup - am i the only one less enthusiastic about that?
14:25 < jrandom> definitely not the only one eco.  
14:25 < jrandom> i wrote the i2ptunnel web interface approximately as poorly as i could
14:25 < jrandom> it really, really sucks
14:25  * cervantes steals jrandom's "patches welcome" line
14:26 < jrandom> (what cervantes said :)
14:26 < jrandom> or even just plain HTML, i can integrate it with the jsp
14:26 < jrandom> (but of course patches to the jsp would be nice)
14:27 < cervantes> jrandom: btw I have a patch for what we discussed yesterday...just going to test it a little more first....
14:27 < jrandom> ah wikked cervantes, thanks!
14:27 < deer> <eco> why not list that in the main page, like the other pages?
14:27 < deer> <eco> ok, so no big religious or technical reason behind it?
14:28 < deer> * polecat has a FUI
14:28 < jrandom> eco: from a UI perspective, it can be made to look like the other pages, but not technically
14:28 < jrandom> technically, it needs to stay seperate as a client app deployed as a seperate .war file
14:28 < deer> <polecat> Ragnarok: I thought you said that's what we've got now?
14:29  * jrandom appreciates very much mihi's contribution of that code, but I can't let the i2p console depend upon GPL
14:29 < deer> <Ragnarok> er, sorry, I meant everything but the signing, which obviously we don't do right now.
14:29 < jrandom> (but we can make it look like the other pages
14:30 < deer> <eco> ah, license issues. great
14:30 < jrandom> heh isn't it grand eco?
14:30 < deer> <Ragnarok> so currently addresses are never updated automatically, changing the destination an address points to always requires user intervention
14:30 < cervantes> jrandom: iframe :P
14:30  * jrandom wishes people just saw the IP farse for what it was and released into the public domain
14:30 < deer> <eco> but in this case a socket connection for example should be okay GPL-wise i'd guess
14:30 < jrandom> cervantes: not an impossible alternative
14:30 < jrandom> right eco
14:31 < jrandom> we've done our best to tap dance around the integration of the actual meat (using clients.config and i2ptunnel.config), but the web UI suffers a bit from it
14:33 < deer> <susi23> any wishes, feature requests, and comments regarding the addressbook interface please add to http://susi.i2p/susidns.html
14:33  * toad_ respects jrandom's extremist licensing views while disagreeing vehemently with them :)
14:33 < jrandom> oh cool, shall do susi23
14:34 < jrandom> heh toad_ :)
14:34 < deer> * eco puts it on his when-i'm-64-to-do-list
14:34 < toad_> bbiab
14:34 < jrandom> l8r
14:34 < toad_> when i get back we need to talk about various technical issues with i2p/freenet integration
14:34 < jrandom> ok, anyone else have anything for the meeting?
14:34  * cervantes wheels out the metal gong
14:34 < toad_> will try to get back quickly
14:34 < jrandom> cool toad_, i'll be around
14:34 < jrandom> (it'll give me time to catch up on those threads ;)
14:35  * jrandom winds up
14:35  * jrandom *baf*s the gong, closing the meeting
14:35 < deer> <DrWoo> jrandom: I have one issue if you're still open to 7)??? , I just want to go back to the azureus plug-in for a moment if I may, #1 - this will be *quite* appealing to the peeps, isn't this the perfect time to try to get easy tunnel length controls into the p2p side of I2P via this plug-in, to try to make the best use of bw resources on the net? #2 - having a working azureus plug-in will (very likely?) cause some publicity whether you want it or not,
14:35 < dm> i2p/freenet integration!?
14:35  * jrandom de-gongs
14:35  * cervantes puts the gong away
14:35 < jrandom> #1: yes, absolutely - I've sent parg a patch to do that
14:36 < jrandom> #2: [got trimmed @ 'want it or not,']
14:38  * jrandom watches the irc streaming lib logs -
14:38 < jrandom> 14:37:55.701: SEND bRC43g==QRnB~Q==: #2          DELAY 1000 MS ACK 1 data: 29 sent 2 times
14:38 < jrandom> 14:38:20.072: SEND juVFdg==aAUIVw==: #3465       DELAY 1000 MS ACK 5723 data: 43 sent 2 times
14:40 < deer> * eco grabs a beer
14:40 < deer> <DrWoo> jrandom: #2 - having a working azureus plug-in will (very likely?) cause some publicity whether you want it or not, are you prepared for a user influx, and if not when do you think you will be?
14:40 < jrandom> it would not be good to have a large burst of users prior to the UDP transport
14:41 < jrandom> there is still a lot of work to be done on azneti2p, so hopefully that'll buy us some time, but we'll do what we need to do
14:41 < deer> <DrWoo> jrandom: cool to see your all over #1 ;)
14:42 < jrandom> we also will need some docs for #1 too, explaining why 0 hops works for some threat models :)
14:44 < jrandom> ok, we ready for a re-gong?
14:45  * jrandom winds up
14:45  * jrandom *baf*s the meeting closed^2