14:09 < jrandom> 0) hi
14:09 < jrandom> 1) 0.4
14:09 < jrandom> 2) Capacity and overload
14:09 * cervantes pulls up a bar stool
14:09 < jrandom> 3) Website updates
14:09 < jrandom> 4) I2PTunnel web interface
14:09 < jrandom> 5) Roadmap and todo
14:09 < jrandom> 6) ???
14:09 < jrandom> 0) hi
14:09 < nicktastic> ugha, Ah, -x isn't even necessary to see what's being resolved - silly me
14:09 < cervantes> hullo
14:09 * nicktastic resumes lurking
14:10 < jrandom> 'lo all, sorry for the delay in the notes - http://dev.i2p.net/pipermail/i2p/2004-September/000437.html
14:10 * jrandom just had to reply to Derick's E post :)
14:10 < deer> <ugha2p> nicktastic: Right. The meeting already started though. :)
14:10 < luckypunk> h wow, i didn't miss it.
14:10 < jrandom> !hi5
14:10 < jrandom> ok, swinging on in to 1) 0.4
14:11 < jrandom> we finally got it out the door, and it doesn't seem to have bitten us too bad
14:12 < jrandom> the network is larger than its ever been (I counted 60 TCP connections a few hours back), eepsites are retrievable, and irc is often usable
14:12 < dm> hey!! meeting?
14:12 < jrandom> hypercubus has done some great work with the new install, systray, and service manager, which I know has helped us out a bunch
14:13 < modulus> yay
14:13 < hypercubus> still a ways to go though
14:13 < hypercubus> but i think we're getting somewhere now
14:13 < jrandom> agreed, ever onwards :)
14:14 < jrandom> this release also has the widespread deployment of oOo's ?i2paddresshelper
14:14 < jrandom> we covered that a bit the other week [http://dev.i2p.net/pipermail/i2p/2004-August/000419.html item 2.3], but now its probably a good idea for people to consider using it for their links
14:15 < hypercubus> does it work with name-based vhosts?
14:15 < jrandom> the i2ptunnel httpclient still correctly sends Host: $base64dest
14:17 < jrandom> on that note, there has been some more talk about using the bundled webserver to serve some eepsites, and i think if someone has some time to figure out the configuration necessary, that'd be pretty kickass (saving us from the vhost / apache config problems)
14:18 < jrandom> ok, anyone else have anything to bring up about 0.4?
14:18 < deer> <baffled> is this web server in cvs?
14:18 < demonic_1> ?
14:18 < hypercubus> the web server is in 0.4
14:18 < demonic_1> what i miss
14:18 < deer> <ugha2p> baffled: It's going to be.
14:18 < hypercubus> hence CVS
14:18 < jrandom> baffled: yeah, its all in cvs (lib/org.mortbay.*)
14:18 < cervantes> btw I experimented with window's url protocol handers... it's very easy to set the registry up so "i2p://base64" will launch in a browser with a http://site.i2p?i2paddresshelper=base64 ...
14:19 < deer> <ugha2p> Oh, it already is.
14:19 < dm> this is all very very cool
14:19 < hypercubus> i already wrote registry interfacing code
14:19 < hypercubus> we can use that to set up an .i2p association
14:19 < fvw> cervantes: i2p:// wouldn't be quite right I think. After all, it's http over i2p; just as you could have irc:// over i2p.
14:19 < cervantes> you can also specify security and proxy settings on a per protocol basis
14:19 < jrandom> cervantes: does firefox/etc honor those?
14:19 < cervantes> yup
14:20 -!- shardy_ is now known as shardy
14:20 < jrandom> woah, hi shardy_
14:20 < shardy> hey jrandom, long time no talk
14:20 < cervantes> although admittedly I need more testing...
14:20 < nicktastic> konqueror should, too
14:20 < cervantes> I was just playing in a spare moment ;-)
14:20 < deer> <ugha2p> Opera doesn't.
14:20 < cervantes> although I doubt firefox takes any notice of windows proxy and security settings
14:20 < hypercubus> you can set it in opera's ini file
14:21 < hypercubus> i did that to opera so ed2k:// would work
14:21 < deer> <ugha2p> hypercubus: Ah, cool.
14:21 < fvw> only up to a point. You can't turn URL handlers into http:// handlers handled by opera itsself alas.
14:21 < hypercubus> though they don't document it very well
14:21 < deer> <duck> really, what benefit does i2p:// give?
14:22 < fvw> hypercube: You're handing it off to a helper app I suppose? I did much the same, but I couldn't find a way to make opera display a "download started" page.
14:22 < hypercubus> yes, it gets handed to eMule
14:22 < dm> yes, who wants to pee in public anyway?
14:22 < hypercubus> we could hand i2p:// to the eeproxy
14:22 < hypercubus> then you web guys can figure out the rest from there ;-)
14:22 < Sciatica> is https not http over, uh, "s"?
14:23 < jrandom> but, as i think duck is getting at, we'll already be tied in to the eepproxy anyway?
14:23 < deer> <ugha2p> Sciatica: It's HTTP over SSL, yes. :)
14:23 < jrandom> Sciatica: http over i2p (well, anything over i2p) is secure and authenticated. what happens after it reaches the other side is outside i2p's scope
14:23 < deer> <ugha2p> But that's an established convention.
14:24 < Sciatica> yes, I knew that. I'm just saying that the argument against i2p:// isn't as clear as "isn't it juts http _over_ i2p?"
14:24 < dm> htt2p
14:24 < hypercubus> i don't know if i2p:// is necessary, but i do believe it's possbile to get the major browsers at least to work with it
14:24 < deer> <ugha2p> jrandom: I think he just referred to the 'https://' prefix.
14:24 < jrandom> ah, sorry.
14:24 < deer> <duck> we need an anonymizing filter plus http://127.0.0.1:7657/www.duck.i2p/ anyway
14:25 < deer> <duck> with those you dont need to tweak browser settings
14:25 < jrandom> but yeah, I agree with fvw, this sounds like excessive overloading of the url protocol
14:25 < demonic_1> not here >> as a lame use i feel i2p:// links would rule << not here
14:25 < jrandom> right duck
14:25 < jrandom> hehe
14:25 < cervantes> perhaps i2p:// could me made to operate as a protocol arbiter: i2p://irc/base64
14:26 < fvw> ungh, that's ugly and abusing URLs in the worst possible way.
14:26 < deer> <ugha2p> cervantes: How would that work in IRC's case?
14:26 < deer> <duck> URIs :)
14:26 < cervantes> that way you can launch different apps based on a single url standard
14:26 < fvw> (not that there's anything wrong with that)
14:26 < jrandom> wouldn't the more appropriate URL mod be irc://i2p/base64/#i2p ?
14:27 < jrandom> but, ok, we're a bit off track..
14:27 < jrandom> anything else on 0.4? :)
14:28 < fvw> I don't think that URI's allow for specifying transport mechanism seperately from protocol, which is a shame really.
14:28 < dm> you can use the filesystem
14:28 < fvw> Yes, sort of: *applause*
14:28 < dm> c:\i2p\irc #i2p
14:29 < dm> ha! I confused you all
14:29 < deer> * mule_iip agrees with fvw
14:29 < fvw> dm: I'm going to seriously hurt you. Maybe not today, maybe not tomorrow, but soon and for the rest of your life.
14:29 < jrandom> :) thanks, we do our best
14:29 < fvw> </pinky and the brain>
14:29 < jrandom> heh
14:29 < jrandom> ok, jumping on to 2) Capacity and overload
14:30 < deer> <DrVince> Hi everyone
14:30 < jrandom> i'd rather not just copy out what was posted in the notes, so review whats there :)
14:30 < dm> hi
14:30 < hypercubus> welcome to our meeting DrVince ;-)
14:30 < deer> <ugha2p> Hi, DrVince.
14:31 < jrandom> one thing I'd like to mention wrt 2) was something a few people have seen - severe skew in participating tunnels
14:31 < jrandom> e.g. someone with DSL had 300+ tunnels the other day
14:31 < dm> me
14:31 < modulus> yeah
14:31 < jrandom> (and when they go down, that breaks a *lot* of tunnels)
14:31 < jrandom> the problem is tunnels are really lightweight - 2-20bps on average
14:31 < cervantes> and my OC3 has practically nada
14:31 < hypercubus> i only have 8 atm
14:32 < dm> i had 270+, and I am on 150kbps
14:32 < jrandom> overall, the network has ~ 20*n tunnels on average at any given time
14:32 < jrandom> (where n = # nodes in the network)
14:32 < jrandom> at an average of 2 hops per node, that means every node participates in an average of 40 tunnels
14:33 < hypercubus> ideally ;-)
14:33 < jrandom> well, thats the thing, balancing like that *isnt* ideal
14:33 < jrandom> since not all nodes are as fast or have as much bandwidth
14:33 < jrandom> on the ohter hand, balancing the tunnels so they all go through 2 or 3 really fast peers also sucks
14:33 < jrandom> since if one of those go down, *boom*
14:34 < hypercubus> right, so why is dm's inferior DSL connection so overloaded, while my much faster DSL connection has been under-utilized?
14:34 < Sciatica> will this problem go away as the # of nodes in the network grows beyond 100, 200, etc.?
14:34 < dm> inferior? :'(
14:34 < jrandom> hypercubus: because i2p is currently nonresponsive to the bandwidth available, unless people turn on bandwidth limiting
14:34 < hypercubus> dm: technically speaking ;-)
14:34 < hypercubus> ok i have bandwidth limiting enabled... dm must not?
14:35 < Sciatica> (at some point won't the number of nodes a server can host be greatly dwarfed compared the the number of total nodes [e.g., tunnels]?
14:35 < ugha_node> Arrr!
14:35 < ugha_node> '(the local message processing time exceeds 1s)' -- I don't think we should program any such constants into the router. I think all such values should be taken from the (I2P network) environment, so it would still work in case the router lands in an unexpected enviromnent.
14:35 < dm> yeah, I don't, also my uplink is decent: 256kbps (downlink 150kbps)
14:35 < Sciatica> bad terminiology -- I type too slow for such issues :-)
14:35 < jrandom> Sciatica: it isn't a problem, is just a reality. if every node maintains 20 tunnels at any given time, with each tunnel an average of 2 hops, no matter how large the network is, it averages out
14:36 < jrandom> ugha_node: agreed - the 1s thing is random #, but how can we derive the "right" value? what amount of delay is "a lot"?
14:37 < jrandom> we do have some code in the RouterThrottleImpl that tracks "how much bandwidth we've agreed to allocate"
14:37 < jrandom> but at the moment, it doesn't throttle based on that
14:37 < dm> hmmmm I don't like these overload discussions... flashbacks of freenet.
14:37 < jrandom> (bandwidth agreed to == # participating tunnels * # messages per tunnel on average * # bytes per message on average)
14:37 < dm> Maybe we should use estimators?
14:38 * jrandom kicks dm
14:38 < hypercubus> dm: are you using bandwidth limiting in your router?
14:38 < dm> hypercubus: no
14:38 < hypercubus> dm: i highly recommend using it ;-)
14:38 < dm> jrandom: three words... NGR
14:38 < fvw> It's really up to the node that requested the tunnel, right? What kind of lag are they willing to put up with? Would it be viable to make it one of the tunnel parameters?
14:39 * fvw wonders if dm is trying to scare us or if it's merely an added benefit.
14:39 < jrandom> hmm, that has potential
14:39 < dm> errr.. won't that just move the arbitrary threshold to the requesting router? ;)
14:39 < dm> I don't want to choose, you choose!
14:40 < jrandom> yes dm, but the requesting router knows what the tunnel will be used for (irc w/ low lag vs bulk w/ high lag and high throughput)
14:40 < fvw> yes, but for some things 10s lag is no problem (think file transfers), whereas other stuff (irc) needs low latency.
14:40 < dm> yeah, so you have the app layer decide the threshold?
14:40 < jrandom> that is, however, dangerous
14:40 < fvw> the only problem is using high-latency links will not increase capacity, so in the end file transfers get all the resources.
14:41 < cat-a-puss> can you really trust any load claims made by the router, otherwise a malicious preson could try to get another nodes traffic to go through all their routers
14:41 < jrandom> cat-a-puss: these are only used to reject requests to participate, not to solicit
14:41 < ugha_node> You can't.
14:41 < cat-a-puss> ok
14:42 < jrandom> a malicious user can of course accept tunnels when they're totally overloaded, but we'll detect that when the tunnel fails
14:42 < jrandom> (and the freeloader can reject the tunnel when they arent loaded, but, c'est la vie)
14:43 < jrandom> the throttle based on local overload is pretty effective though. however, that isn't enough
14:43 < dm> greedy bastard
14:43 < jrandom> i've been trying to find out an ideal way to work out whether to accept it or not, and i think that there is some potential for probabalistically rejecting requests we would otherwise accept, based on how many tunnels we are already in
14:44 < jrandom> the concept there is that the peer wants other people to take on some load
14:44 < cat-a-puss> should we run as many virtual routers as avalable bandwidth?
14:44 < jrandom> (so as to distribute the failure)
14:44 < jrandom> hmm cat-a-puss?
14:44 < jrandom> are you running the sim on the live net?
14:45 < jrandom> in any case, no, a single router should be able to address the local capacity
14:46 < deer> <mule_iip> problem is that bandwidth used in a tunnel may change significantly over time, right?
14:46 < cervantes> which is not currently happening...at least not for me
14:46 < cat-a-puss> well if it's all random how can you take advantage of an oc3 any more than some poor guy on a 56k? You ether have to advertise: problematic, or run virtual routers, ether way I think a malicious party could try to encircle a node for some sort of stistical attack
14:46 < jrandom> right mule_i2p. we need to do some more monitoring of the tunnel activity
14:46 < cervantes> 14 participents each have 11.5mbit ... that's a bit of a waste :)
14:47 < jrandom> cat-a-puss: probabalistic != random :)
14:47 < jrandom> heh cervantes
14:48 < jrandom> the basic idea behind probabalistically rejecting would be to spread the load out to other peers. however, if the network really is saturated, the probability won't be a problem as people will just ask again
14:48 < jrandom> the issue is that we currently have an overwhelming *excess* of capacity
14:48 < Sugadude> Poor i2p, having *too* much capacity. Don't worry, I'm on it. ;)
14:49 < fvw> assuming everyone is wellbehaved, you could perhaps not reject from people who come back within a short interval of being probabilisticly rejected?
14:49 < deer> <mule_iip> so fill any tunnel with some cover traffic
14:49 < jrandom> heh Sugadude :)
14:49 < cervantes> that's because everyone's requests are being handled by dm's router ;-)
14:49 < jrandom> fvw: we dont know who requests a tunnel
14:49 < fvw> hmm, good point. *screws head back on*
14:50 < jrandom> fvw: probabalistically, subsequent requests would be accepted - we'd want the 'reject' factor to stay low enough
14:50 < deer> <mule_iip> which will increase anonymity and make load calculation easier
14:51 < jrandom> true mule_iip, but it'd be nice to actually have the net operate effectively without requiring high load :)
14:51 < jrandom> but that is definitely a worthwhile scenario for the sim
14:51 < deer> <mule_iip> effectively make i2p use a constant bitrate with cover traffic. but that was for a future release, i guess :)
14:52 < jrandom> we *could* use ATM-style allocation
14:52 < fvw> Doesn't bandwidth usage vary too much for that to be viable?
14:52 < jrandom> e.g. assume 5 messages per minute per tunnel @ 32KB each, and compare that with the bandwidth limits, and reject accordingly
14:52 < cervantes> hyper has some ascii we can use to pad the messages out
14:52 < hypercubus> hmmmm, i don't like that constant bitrate idea... i2p would be filtered by ISPs very quickly if that were implemented
14:53 < jrandom> heh cervantes
14:53 < deer> <kaji> yes
14:53 * hypercubus doesn't know what cervantes is talking about
14:53 * hypercubus hides his floppy
14:53 < jrandom> fvw: padding? or allocation?
14:53 < fvw> allocation
14:53 < cervantes> ah ya plausable deniability huh
14:54 < jrandom> hmm fvw. perhaps, but I think we can monitor them statistically and compensate
14:54 < deer> <kaji> constant bitrate sounds like Waste
14:54 < jrandom> for instance, http://localhost:7657/oldstats.jsp#tunnel.bytesAllocatedAtAccept
14:54 < hypercubus> hence its name ;-)
14:55 < jrandom> that stat monitors how much bandwidth we have agreed to pass on for other people's tunnels
14:55 < jrandom> (using the last 10 minutes as a guideline)
14:56 < jrandom> so my peer with 85 tunnels says it will transfer 3,676,945.65 bytes over the next 10 minutes for all of those tunnels, combined
14:56 < deer> <mule_iip> kaji: it is waste, and we probably should use it only for the more severe threat models. but would be nice for low latency like irc.
14:56 < jrandom> thats 72bps each, but I'm not sure how skewed it is (probably *very*)
14:57 < jrandom> however, if all of those tunnels started using lots and lots of bandwidth, the total value would shoot up, and we could throttle it
14:57 * fvw nods.
14:57 * fvw notes this is in fact a wildly interesting problem, theoreticly speaking.
14:57 < fvw> (but maybe that's just me being weird)
14:57 < jrandom> agreed
14:58 < jrandom> (to both ;)
14:58 < jrandom> but yeah, we dont have the Right Answer yet. but its something to be worked on
14:59 < jrandom> ok, unless there's anything else on that, moving on to 3) Website updates
14:59 < fvw> We could ofcourse go totally lossy and just drop datagrams when we're overloaded, and make people run something like tcp over that.
14:59 < jrandom> we tried that, and lots and lots and lots of tunnels failed
15:00 < jrandom> (since if a tunnel drops 1 message, we mark it as failed)
15:00 < fvw> yes, you shouldn't do that if you take that approach.
15:00 < jrandom> ((and when we tried not being such fascists, we didn't notice when a tunnel *really* fails))
15:00 * fvw nods and strokes his beard. Good point. (mental note to self: grow beard to stroke in situations like this)
15:01 < jrandom> heh
15:01 < jrandom> ok, anyway, as you've all seen, our new installer and new web interface is completely different from the old way of doing things
15:01 * hypercubus gives fvw his beard
15:02 < jrandom> while that is Good, since the old way was Painful, all our old docs are now wildly incorrect
15:02 < fvw> could we stick on 2) a few minutes longer? I still have a few bad ideas I want you to shoot down.
15:02 < jrandom> sure
15:02 < dm> I can't use the internet...
15:02 < dm> Bandwidth in/out
15:02 < dm> 1m: 13.32/11.98KBps
15:02 < dm> 5m: 10.74/9.46KBps
15:02 < jrandom> how many tunnels dm?
15:02 < hypercubus> dm: that's why i suggested you turn on i2p's bandwidth limiting ;-)
15:02 < dm> only 166
15:02 < jrandom> yeah, throttle it down to 6KBps
15:02 < jrandom> lol
15:03 < dm> (participating)
15:03 < jrandom> (or maybe 8KBps if you're nice)
15:03 < dm> I'll leave it as is, I just need to view this one page
15:03 < jrandom> btw, the 13.32 vs 11.98 lets us know you're downloading approximately 1KBps locally
15:03 < jrandom> (through i2p)
15:03 < fvw> What happens if we just time-out tunnels at a reasonably large idle-time? Say 30 mins or something. The next protocol up would have to do keepalives, but wouldn't that solve the not-detecting-dead-tunnels thing?
15:03 < hypercubus> he's downloading far more than that actually
15:04 < jrandom> ((though that 1KBps might be small enough to be netDb))
15:04 < dm> hypercubus: our transfer is stalling badly, actually.
15:04 < jrandom> fvw: tunnels expire after 10 minutes
15:04 < deer> <kaji> hold it, is bandwidth working now? if so what sould i turn it to?
15:04 < dm> dissapointed in the getright/i2p combo
15:04 < jrandom> they're not long lived fvw, unlike TOR
15:04 < fvw> and that had most tunnels failing, even with keepalives?
15:04 < hypercubus> dm: periodically yes... i think the solution would be to limit your upstream to about 8KB/s
15:04 < jrandom> kaji: http://localhost:7657/
15:05 < hypercubus> since it seems you're saturated
15:05 < jrandom> er, /config.jsp
15:05 < fvw> ok, but you don't want them dissapearing in flurries of packet loss.
15:05 < jrandom> every minute (on average) each peer tests each tunnel to make sure its alive (so that other people can send us data - without tunnels, we're fucked)
15:06 < fvw> Ok. I need to read more of how i2p currently works. On to 3) as far as I'm concerned.
15:06 < deer> <kaji> right now its set on the default -1 but I dont know what a 1.5/750@1.2ghz connections translates to from maximum tunnel partisipation
15:07 < deer> <kaji> i seem to be participation in 166
15:07 < jrandom> kaji: your router will never get so many tunnels that it'll be CPU congested ;)
15:07 < deer> <mule_iip> off-topic: don't you need a tunnel to be fucked :)
15:07 < deer> <kaji> *ing
15:07 < jrandom> heh
15:07 * fvw votes "nay"
15:08 < deer> <kaji> jrandom, i just finnished reading the letter about tunnels without bandwidth, i just didnt know what to set the limmit to
15:08 < jrandom> ok, i agree, lots more to be done to figure this stuff out
15:08 < jrandom> ok cool kaji, just enable your bandwidth limiter to something like 8KBps
15:08 < jrandom> (or 12 if you're nice :)
15:09 < deer> <kaji> </oftopic>
15:09 < jrandom> ok, on to 3) website updates
15:09 < deer> <kaji> inbound and outbound?
15:09 < jrandom> yes kaji
15:09 < jrandom> ok, as I said, we need help with the docs
15:09 < jrandom> (heeeeeeeeelp!)
15:09 < hypercubus> i move we fill the long-vacant team positions of Webmaster and Web Editor
15:10 * jrandom seconds that motion
15:10 < jrandom> (now all we need is someone to volunteer ;)
15:10 < hypercubus> i know cervantes is a busy guy
15:10 < jrandom> its more up to the invidual to volunteer /themselves/ hyper ;)
15:10 < hypercubus> i nominate Curiosity for Webmaster or Web Editor, or both if she's up for it ;-)
15:11 < deer> <ugha2p> Uhh.
15:11 < dm> Man, even my CPU is starting to max out because of I2P...
15:11 < dm> You love, you REALLY love me :'(
15:11 < dm> oops, :')
15:12 * cervantes feels someone pushing him into the bull ring
15:12 < jrandom> i think we can use all the help we can get, and if she is up for helping, we'd love it
15:13 < hypercubus> i've seen her web designs and can vouch for her work
15:13 < hypercubus> and she expressed interest, i don't know what she finally decided however
15:13 < jrandom> ok great
15:13 < dm> she?
15:13 < cervantes> I'm sure she can devote far more care and attention to it than I ever could
15:14 < dm> that word must not be used in our world
15:14 < fvw> never mind that, he said 'care and attention'.
15:15 * jrandom groans
15:15 < fvw> present company excluded ofcourse.
15:15 < jrandom> ok, in any case, we'll need some people to help out on the docs - generating new walk throughs, intro docs, etc
15:16 < jrandom> we'll chat with Curiosity about what we can get her to hack on :)
15:16 < hypercubus> i can take on the installation related stuff
15:16 < hypercubus> s/on/of/
15:16 < hypercubus> i know how everyone loves to read these baroque howto's that i write ;-)
15:16 < jrandom> :)
15:17 < jrandom> an install guide / walkthrough would KickAss
15:17 < fvw> that's not how you spell 'broke'.
15:17 < jrandom> heh
15:17 * hypercubus snickers, then steals fvw's wallet
15:17 < hypercubus> that's how you spell "broke" ;-)
15:17 < deer> <kaji> hyper what system are you on? i'll take a crack on the winxp version but im not very reliable, i may see something shiny and quit
15:17 < deer> * Curiosity is away for a bit...
15:18 < hypercubus> kaji: ?
15:18 < deer> <kaji> hyper, i was asking what OS you are using
15:18 < hypercubus> OSes
15:18 < deer> <kaji> OSESES
15:19 < hypercubus> i have vmware, so i can run all the windowses and freebsd and such
15:19 < hypercubus> also have pearpc, so i can run OS X
15:20 < jrandom> ok, if there's nothing else on the web side
15:20 < jrandom> moving on to * 4) I2PTunnel web interface
15:21 * jrandom declares the i2ptunnel web interface shitty. functional. but shitty.
15:21 < deer> <DrVince> I could dig in for french translation if interest may be
15:21 < jrandom> duck had a few ideas for improving it, but he had to jet, so let me paste a few lines
15:21 < hypercubus> again, we need more web devs ;-)
15:21 < jrandom> oh, translating web pages to french would rule
15:22 < jrandom> s/french/french and other langs/
15:22 < jrandom> here are some duck-isms:
15:22 < jrandom> <duck> reduce data load on general page; use tables/div to order stuff
15:22 < jrandom> <duck> provide a edit/detailed page with info most dont care about, tunnels, dest hash, full key
15:22 < jrandom> <duck> feedback after clicking buttons, 'item saved' etc. give dest as output when new one created
15:22 < jrandom> <duck> (hide under edit/details otherwise)
15:22 < jrandom> <duck> tag the top messages as being 'log'; sometimes confusing
15:22 < jrandom> <duck> make clear that 'confirm' is only needed for remove, not save
15:22 * jrandom agrees with what he says
15:23 < jrandom> there have been a slew of bugfixes behind the scenes in the /i2ptunnel/ web interface since 0.4 too, so the functional kinks should be cleaned up
15:24 < jrandom> the code implementing those pages are pretty ugly though
15:24 < jrandom> probably the best approach would be to write up the screens in plain html / css / images / etc, then give it to one of the java devs to integrate
15:25 < hypercubus> whatever happened to the days when there was an overabundance of web devs? ;-)
15:25 < jrandom> they're all working at mcdonalds
15:25 < hypercubus> ah right
15:25 < deer> * Curiosity is back :)
15:25 < jrandom> anyway, if anyone is interested in helping out, or has further suggestions, please get in touch
15:25 < jrandom> wb Curiosity
15:26 < deer> <Curiosity> should i bring up the idea i told oyu about jrandom?
15:26 < cat-a-puss> I know someone who might be able to help with the web stuff
15:26 < jrandom> ah, the live cd?
15:27 < jrandom> great cat-a-puss, we need all the help we can get
15:27 < deer> <Curiosity> teah :)
15:27 < deer> <Curiosity> err yeah
15:27 < jrandom> Curiosity: yeah, please bring that up when we get to item 6) ???
15:28 < deer> <Curiosity> okay :)
15:28 < cat-a-puss> ok, I'll get them on the list, and give them jrandom's e-mail (curiosity I don't know your email)
15:28 < jrandom> ok, does anyone have anything else to mention regarding the I2PTunnel web interface?
15:28 < jrandom> r0x0r cat-a-puss
15:29 < deer> <Curiosity> also, i don't mind helping wiht the web editing, etc. also :)
15:29 < jrandom> ok, if there's nothing else, 5) Roadmap and todo
15:30 < jrandom> awesome Curiosity, thanks! we can chat a bit after the meeting about taking over the world^W^W^W^Wweb stuff
15:30 < deer> <Curiosity> okies :)
15:30 < jrandom> as y'all probably saw, there's a new big scary page on the website (http://www.i2p.net/todo)
15:31 < jrandom> that covers the big scary issues we have ahead of us (and doesnt even touch on all the client apps we need, etc)
15:31 < jrandom> as you can see, we've got a shitload to do, but the good news is, we dont have to have it all done right away.
15:32 < jrandom> in fact, those things are really just the bullet items from the roadmap page (with a heap of text introducing each)
15:33 < jrandom> while i know thats a lot to sort through, what would be great is if people could let me know if they come across something that we will need to deal with that isn't on that page
15:34 < jrandom> that isn't necessary today or this week even, just a general "hey, let us know"
15:35 < jrandom> with mule's suggestion (http://www.i2p.net/todo#nat) i've been doing a lot of soul searching, and the roadmap will likely be moved around a bit
15:35 < jrandom> but we'll see.
15:36 < jrandom> if you have any strong feelings on certain issues ("omg we *cannot* function without X, Y, and Z!"), please let me know or post onto the list
15:36 < jrandom> while i'm no champion of democracy, i am open to reason :)
15:37 < jrandom> ok, thats all i've got to say about that.. anyone have anything to throw out there?
15:37 < deer> <Curiosity> benevolent dictatorship :)
15:37 -!- Sonium_ is now known as Sonium
15:37 < jrandom> bah, i'm no dictator - i dont control what other people code :)
15:37 < cervantes> tranquil hegemony
15:37 < cat-a-puss> I've aquired two more developers
15:37 < jrandom> w00t!
15:38 < cat-a-puss> and have grand plans for a distributed search engine
15:38 < jrandom> oh, kickass
15:38 < jrandom> would that be something http://files.i2p/ could tie into?
15:38 < jrandom> or, well, let me just say, oh, kickass :)
15:38 < cat-a-puss> er: I can't get there (hostile enviroment)
15:39 < jrandom> ah 'k
15:39 < cat-a-puss> anyway, some CVS space would be nice, once we get there
15:40 < jrandom> certainly, space on cvs.i2p is available
15:40 < jrandom> either within the i2p/apps/ directory or your own module, if preferred
15:40 < jrandom> (cvs.i2p == cvs.i2p.net)
15:40 < cat-a-puss> I should probably talk to the people working on the dht huh?
15:41 < cat-a-puss> what is the status of that thusfar
15:41 < jrandom> :)
15:41 < jrandom> i haven't heard any status updates from aum in the last few days, but i'm sure he's churning away
15:42 < jrandom> last update was in http://dev.i2p.net/pipermail/i2p/2004-August/000425.html
15:43 < jrandom> ok, i guess that moves us on to * 6) ???
15:44 < jrandom> Curiosity was bouncing around the idea of a 'live cd' idea with i2p
15:44 < jrandom> which i think is pretty cool, and something we will want
15:44 < deer> <Curiosity> kewl :)
15:44 < jrandom> though we aren't really stable enough for that yet, with a release every 2 weeks or so
15:44 < hypercubus> agreed... it could even be integrated into a Knoppix ISO
15:45 < deer> <Curiosity> ?
15:45 < hypercubus> Knoppix, a livecd distro of linux
15:45 < hypercubus> very user friendly
15:45 < deer> <Curiosity> k
15:45 < jrandom> though once we have the Really Simple Update functionality that is a one click download from http://dev.i2p/i2p/i2pupdate.tar.bz2, it might not be too bad
15:46 < jrandom> Curiosity: do you have anything else you want to discuss about that?
15:46 < fvw> ...and as soon as it becomes widely used, anyone controlling dev.i2p can compromise the network.
15:47 < jrandom> as long as people use that Really Simple Update functionality
15:47 * fvw nods.
15:47 < deer> <Curiosity> i just wanted a way for people to run it w/o having to download a bunch of stuff onto their computer
15:47 < jrandom> (and if dev.i2p is compromised, we put up a new hosts.txt entry for dev.i2p)
15:48 < hypercubus> a knoppix i2p livecd would be prime for cybercafe use
15:48 < deer> <mule_iip> jarndom: won't a real i2p user grab the source, study the diff against the latest peer reviewed version and build from source :)
15:48 < fvw> yes but people will just hit 'update'; They won't listen to discussions about whether the new version might have vulnerabilities...
15:48 < demonic_1> is there anyway to not need hosts file. u know like a dns server?
15:48 < deer> <Curiosity> yeah... riiiight mule_iip. lol
15:49 < fvw> but anyway, I'll be very happy when we get to the stage where this becomes a problem.
15:49 < fvw> demonic_l: It's possible, but there'd still be a central authority.
15:49 < hypercubus> demonic_1: there are currently a couple of proposals for such functionality, but global names have been ruled out
15:49 < jrandom> demonic_1: yes, see the mailing list (recent discussions on http://dev.i2p.net/pipermail/i2p/2004-September/000432.html )
15:49 < jrandom> (and my take @ http://dev.i2p.net/pipermail/i2p/2004-September/000435.html :)
15:50 < hypercubus> *globally unique names
15:50 < demonic_1> k
15:51 < jrandom> ok, anyone have anything else they want to bring up?
15:52 < deer> <Curiosity> I would also like ot suggest putting service only items into a service folder... i was trying to uninstall i2p (one time of many) and was hitting the wrong uninstall thingie
15:52 < hypercubus> Curiosity: that's being done
15:52 < jrandom> w3rd
15:52 < hypercubus> the installer will install shortcuts for i2p to the Start menu in Windows
15:52 < hypercubus> and optionally on your desktop
15:52 < deer> <Curiosity> okies :)
15:52 < hypercubus> among them will be "uninstall"
15:53 < deer> <Curiosity> i was talking about when i go into program files/i2p
15:53 < hypercubus> you don't need to from there
15:54 < hypercubus> Windows users don't ever go into the program folders ;-)
15:54 < demonic_1> :/
15:54 < deer> <Curiosity> i do! :P
15:54 < jrandom> we could perhaps add a bin/ dir with all the scripts
15:54 < jrandom> er, nm
15:54 < hypercubus> then you would have seen the folder called "Uninstall" ;-)
15:54 * jrandom remembers the paths
15:54 < hypercubus> which is where the uninstaller is located
15:54 < jrandom> we can move the service scripts into lib though
15:54 < hypercubus> i'm not sure we can
15:55 < cervantes> you could go the 'doze method and have the "uninstall" option in the installer ;-)
15:55 < hypercubus> wrapper is very particular about where you put those
15:55 < jrandom> at the very least they can "cd .." first
15:55 < hypercubus> i'll look into changing their location
15:55 < hypercubus> but it might not be doable
15:55 < jrandom> cool, thanks. it'd be nice to remove some of the clutter in the install dir
15:55 < hypercubus> agreed
15:55 < jrandom> (most of which is my fautlt with all those .config files :)
15:56 < hypercubus> we could have a config dir i guess
15:56 < cervantes> ./conf ?
15:56 < jrandom> c'mon, we're geeks. etc/ :)
15:56 < jrandom> that would be Really Easy though
15:56 < jrandom> (just a few -D parameters on the CLI)
15:56 < hypercubus> then we'll have to field questions from Windows users that "etc" isn't obvious enough ;-)
15:56 < jrandom> people shouldnt need to touch their config
15:57 < jrandom> thats what the web is for
15:57 < cervantes> I've always gone for the blatant: ./configuration/
15:57 < hypercubus> right, but Windows users shouldn't need to launch the uninstaller from their program directory either heheh
15:57 < jrandom> ./thesefilestellstufftodothings/
15:57 < cervantes> ./scripts/
15:57 < cervantes> ./asciipr0n
15:57 < jrandom> ok, but yeah, some work we can flesh out
15:57 < deer> <Curiosity> lol
15:58 < jrandom> anyone have anything else to bring up for the meeting?
15:58 < jrandom> if not
15:58 * jrandom winds up
15:59 * jrandom *baf*s the meeting closed