13:12 < jrandom> agenda:
13:12 < jrandom> 0) hi
13:12 < jrandom> 1) administravia
13:13 < jrandom> 2) 0.3 status
13:13 < jrandom> 3) peer profiling / selection
13:13 < jrandom> 4) web architecture
13:13 < jrandom> 5) ???
13:13 < jrandom> 0) hi
13:13  * jrandom waves to the gang
13:14 < deer> * jrandom_ waves from i2p
13:14 < deer> * wilde hi5s
13:15 < deer> <ughabugha> Hi!
13:15 < deer> * duck is reading
13:15 < deer> <human> yo!
13:16 < jrandom> w0rd, sorry for the delay getting those status notes up at (http://i2p.net/pipermail/i2p/2004-March/000165.html)
13:18 < jrandom> 1) administravia
13:19 < jrandom> for simplicity, and to avoid the trouble we had last week w/ the various networks being bitchy, some magic has been worked out and this meeting is being run off three irc networks
13:19 < deer> <duck> (amazing!)
13:19 < jrandom> iip's #i2p, the duck/baffled i2p irc network's  #i2p, and freenode's #i2p
13:19 < jrandom> :)
13:19 < deer> <baffled> who's paranoid?
13:20 < deer> <ughabugha> Ok, done reading the status notes.
13:20 < deer> <ughabugha> jrandom: What about it?
13:20 < deer> <ughabugha> Or them?
13:21 < jrandom> just mentioning it, so people who have trouble with one can use another
13:21 < deer> <mihi> fine. done with status notes as well
13:21 < jrandom> also, the drupal box should be back online this weekend (crossing fingers)
13:22 < deer> <ughabugha> Oh, ok. Is there anything to discuss on 1)?
13:22 < deer> <ughabugha> Or are we waiting for people to finish reading?
13:22 < deer> <ughabugha> jrandom: Good. :)
13:22 < jrandom> nope, unless anyone has any administravia they'd like to bring up?
13:23 < deer> * mihi wants to set a flag at point 3
13:23 < jrandom> flag set ;)
13:23 < deer> * duck at point 2
13:23 < deer> <duck> err, what index do we use?
13:24  * jrandom supposes we can move on to agenda item 2) 0.3 status
13:25 < jrandom> i ended up typing a lot more than usual for the 0.3 status notes, so rather than repeat them here, does anyone have any questions / concerns they'd like to bring up?
13:25 < deer> <ughabugha> Go on.
13:26 < deer> <duck> why do the ElGamal/AES+SessionTag decryptions fail too often?
13:26 < jrandom> duck> due to overload and lag.  if a garlic routed message is delayed beyond that sessionTag's lifetime, the decryption will fail
13:27 < deer> <duck> k
13:27 < jrandom> in addition, if the garlic routed message is decrypted fine, but the content was delayed so much that the cloves expire, its a wasted decryption, as well
13:28 < deer> <duck> somehow that sentence made me believe that there was a cause besided the overload/lag
13:28 < deer> <tro|l> ce zi e azi?
13:28 < jrandom> well, there have been some troubles with source routed reply blocks failing decryption, though since they're going away in 0.3.1, its not really worth debugging them too much
13:29 < deer> <kaji> wow it works!
13:29 < jrandom> (and a failed ElG is probably the most CPU intensive thing i2p does)
13:30 < deer> <jrandom_> heh welcome to i2p #i2p :)
13:30 < deer> * kaji praises 0.2.5.1
13:30 < deer> <jrandom_> 0.2.5.1?  sheeit, get thee 0.2.5.4 :)
13:30 < jrandom> ok, anything else for 0.3 status?
13:31 < deer> <kaji> ..
13:31 < deer> <duck> .
13:31 < deer> <kaji> ping?
13:31 < jrandom> p0ng
13:31 < mihi> pung
13:31 < deer> <mihi_backup> pung2
13:32 < deer> <Pellinore> prawn
13:32 < jrandom> ok, moving on to 3) peer profiling / selection
13:32  * mihi moves the flag to the other number 3 ;)
13:32 < jrandom> (man, its kind of funny that there isn't any vegetarian seafood substitutes...)
13:32 < deer> * kaji praises 0.2.5.4.1
13:32 < deer> <duck> the whole peer profiling thing looks at magic, how do you plan to debug that?
13:32 < deer> <Pellinore> There is vegetarian crabmeat.
13:32 < jrandom> ah, true pellinore.
13:32 < deer> <wilde> jrandom: and veg sushi
13:33 < jrandom> duck> what part of it looks like magic?
13:33 < deer> <duck> the whole classification etc
13:33 < deer> <Pellinore> And I could have sworn that I had seen some chik-type fish fillet substitute, but I could be wrong.
13:33 < deer> <duck> I mean, how do you know that you are doing optimal things?
13:33 < jrandom> the peer organizer (which moves profiles into the different groups) is a very simple and seperable component
13:33 < jrandom> oh, thats a good point.
13:34 < jrandom> i was doing some benchmarking the other day, running the organizer with 10,000 profiles, and it was organizing them all un ~50ms
13:34 < jrandom> (organizing == runningthe calculators and moving them between groups)
13:34 < jrandom> profiles also consume only ~3-4KB for a full profile, and a minimal profile takes ~200 bytes
13:35 < deer> <duck> yeah, but how do you know that you are right with '0.597s reply' for group 1
13:35 < deer> <duck> and that it shouldnt be 0.603s
13:35 < jrandom> (so we'll keep a full profile of the best 1000 peers, and minimal of the next 10,000)
13:35 < jrandom> ah, ok, good question.
13:36 < jrandom> thats the Rate component
13:36 < jrandom> there will obviously be some flutter, and we won't be very exact.  the goal ois to get ballpark and organize them accordingly
13:37 < deer> <duck> I did see it using averages
13:37 < jrandom> e.g. find the routers on T3s with quad procs, and keep them seperate from routers on 386s with 2400 bps modems
13:37 < deer> <duck> so if you throw in 100 shitty nodes, you heavily influence the average
13:37 < jrandom> agreed - there are two different aspects of that that we can tune
13:38 < jrandom> first, we can make the threshold use the top 10% to determine the "fast" vs "not fast"
13:38 < jrandom> (or top 90%, whichever)
13:38 < jrandom> second, we can adjust the Rate component to keep various statistics - rather than a simple average, it can ignore skew, find stddev, etc
13:39 < jrandom> the rate component currently is quite remedial, and I'd love if someone good with stats could take a look at it and fix it up
13:39 < jrandom> (one of the key goals of it however is to keep it scale free - so if we get 100,000 events, it doesnt have to keep all those data points in memory, etc)
13:40 < deer> <duck> ok, so what prevents another NGRouting disaster from happening?
13:40 < jrandom> but you're absolutely right - the calculators and the peer selection algorithms are going to be a major focus of future network improvements
13:40 < jrandom> ngrouting tried to do two different things - find particular data, and find available peers.
13:40 < jrandom> we only need to find available peers
13:41 < deer> <duck> good
13:41 < jrandom> (and place our tunnels there)
13:41 < deer> * duck removes breakpoint
13:41 < jrandom> :)
13:41 < mihi> but we have to find tunnels as well.
13:41 < jrandom> right mihi - the netDb is an important point
13:42 < deer> <Pellinore> I'm good with the math of statistics, but terrible with the tech aspects of translating the data into computer-useful data.
13:42 < deer> <Pellinore> But I would happily partner up with someone and contribute if I can.
13:42 < jrandom> awesome pellinore!
13:43 < jrandom> the main rate class is up at http://i2p.net/cgi-bin/cvsweb.cgi/i2p/code/core/java/src/net/invisiblenet/i2p/stat/Rate.java?rev=1.3&amp;content-type=text/x-cvsweb-markup and we can talk later to discuss it :)
13:43 < deer> <Pellinore> k
13:43 < jrandom> (i know, i don't expect you to read the code, just mentioning it)
13:44 < deer> <Pellinore> I'll read it, but it will be about like my dog reading Kierkegaard.
13:44 < jrandom> hehe
13:45 < deer> <Pellinore> But I am learning.
13:45 < deer> <Pellinore> Anyway, please proceed -- I don't mean to bog things down.
13:45 < jrandom> (volunteering to help isn't bogging things down ;)
13:46 < jrandom> one point i forgot to mention about the peer profiling / selection code is that the 'integration' rank is only used in the network database for 'exploration', not for search/store
13:46 < jrandom> we still do (fairly) traditional kademlia search/store with all non-failing peers
13:46 < jrandom> also, within each peer group, we always choose *randomly*
13:46 < jrandom> (aka we don't always choose the fastest of the fast group, etc)
13:47 < jrandom> thats for both security and load balancing reasons
13:48 < jrandom> (security, so that an attacker can't just create a really fast router and watch everyone make use of them - they have to create a large number of really fast routers, skew the entire distribution in their favor, etc)
13:49 < jrandom> ok, do we have anything else for 3) peer profiling / selection?
13:49 < deer> <duck> .
13:50 < deer> <ughabugha> Doesn't look like it.
13:50 < jrandom> ok, moving on to 4) web architecture
13:52 < jrandom> mihi's new streaming lib gives us a lot of flexibility, plus he's mentioned a few times the desire to factor out the httpclient code into something more robust.  in addition, human has started updating things to allow transparent squid(or tor-www) proxying and eepsite proxying within the same client
13:52 < jrandom> given all of these different factors, and the likelyhood that web like functionality will be important for i2p's user base, i think we should take a step back and try to envision how it should all fit together
13:53  * mihi has some code flying around on my hd for that httptunnel code. but it's far from being finished
13:53 < mihi> for me httptunnel == httpclient + some filters
13:53 < mihi> of course using my naming and streaming api.
13:54 < mihi> the code atm only allows different "anonymity profiles".
13:54 < jrandom> any thoughts on human's style of failing over to outproxies like squid/etc?
13:54 < mihi> i.e. send all requests over one destination, mux them up to 10, mux them up to one dest per hostname, etc.
13:54 < jrandom> ah, interesting
13:55 < mihi> but these dests are not used yet ;)
13:55 < jrandom> w3rd.  yeah, there *is* the big caveat that having lots of destinations on one router does increase CPU load nontrivially
13:55 < jrandom> (since any garlic fail will need to fail once per dest before failing completely)
13:56 < jrandom> there is some magic left that can be used to minimize that though, i think
13:56 < deer> <ughabugha> Are you sure the transparent squid proxying is a good idea in the performance point of view? I mean, people might get too lazy and not take their eepproxy off after browsing I2P sites or using I2P squid, therefore wasting I2P bandwidth for things that don't require anonymity.
13:56 < jrandom> ughabugha> all things require anonymity :)
13:57 < jrandom> (and if they can't tell the difference, well, sheeit...)
13:57 < mihi> my intention for httptunnel is that http links will be rewritten (similarly to fproxy) so that you don't need a proxy but only a servlet.
13:57 < deer> <ughabugha> jrandom: Heh. That way, I2P was born dead. There isn't going to be enough available bandwidth on the network, that all the endnodes would likely consume.
13:58 < mihi> on that info page one might add a feature to browse the site throufh e.g. squid.
13:58 < jrandom> not quite sure i follow.  i do understand and agree with the DNS issues involved (though i think we can get around them a few ways)
13:58 < jrandom> ah, ok mihi
13:58 < deer> <aum> morning all
13:58 < jrandom> mihi> so like a much much more advanced "Unable to reach peer" page?
13:59 < mihi> more like a "anonymity warning" page like in freenet ;)
13:59 < jrandom> ughabugha> if we cant handle web browsing, how are we going to handle BT/filesharing?
13:59 < jrandom> hmm mihi, but do we want that, for people who want to browse the web anonymously?  or would httpclient not be the app they'd use?
14:00 < jrandom> 'mornin aum, just in time for the dev meeting :)
14:00 < mihi> jrandom: if someone just wants to browse the web anonymously, he
14:00 < deer> <ughabugha> jrandom: Hmm... Good point. Are we going to at all? ;)
14:00 < deer> <aum> jrandom: you're not on iip, you're not on irc.duck.i2p ?!?
14:00 < jrandom> ughabugha> we must.
14:01 < mihi> might configure httptunnel to so so (httptunnel will still work as a proxy, so it's quite trivial to add that)
14:01 < mihi> and most likely someone browsing the web "anonymously" will like some content filters, i guess ;)
14:01 < jrandom> mihi> i think human already did :)
14:01 < jrandom> agreed mihih
14:01 < jrandom> /hih/hi/
14:02 < mihi> when i say httptunnel, i don't mean httpclient ;)
14:02 < jrandom> ah ok
14:02 < deer> <jrandom_> i'm here aum ;)
14:02 < mihi> but we *really* should move i2ptunnel to use the streaming api ASAP, which will reduce the number of files we must maintain
14:03 < jrandom> agreed
14:03 < mihi> human only patched the old version, i patched the new version myself
14:03 < jrandom> we ran into some bugs this afternoon, not sure if human bounced you logs yet
14:03 < deer> <wilde> another thing for the list: outproxy was taken, but more like i2p2i
14:04 < mihi> i did not get logs yet from anyone...
14:04 < jrandom> mihi> we'll get on to the streaming code asap, we can talk about it after the meeting if you've got a moment, or over email?
14:04 < deer> * aum spent part of yesterday looking at p2p apps with a view to running them on i2p
14:04 < jrandom> wilde> hmm?
14:04 < jrandom> wikked aum, anything promising?
14:04 < deer> * aum is presently inclined to favour 'push'-type filesharing, eg konspire2b
14:05 < jrandom> i2psnark could be modified to use the new i2ptunnel streaming api fairly easily too
14:05 < deer> <human> mihi: sending the logs (mihi@i2p.net, right?)
14:06 < mihi> dunno if mihi made a redirect for me
14:06 < deer> <mihi> s/mihi/jrandom
14:06 < jrandom> hmm aum, do you think that freenet/insert model really would work most effectively?
14:06 < deer> <wilde> jrandom: i was thinking of using a i2p webserver -> proxy -> internet, so people can browse a i2p site, but maybe an ordinary tunnel can manage the traffic
14:06 < jrandom> mihi> want me to set that to for ward to you?
14:06 < mihi> jrandom: nothing against it ;)
14:07 < deer> <ughabugha> aum: 'Push'-type? What's that?
14:07 < deer> <aum> what i like about konspire2b is it takes away the expectation for instant/prompt delivery, and reduces bandwidth requirement, by only broadcasting content announcements, then letting people 'subscribe' to 'content feeds'
14:07 < jrandom> mihi> done.
14:08 < deer> <aum> so instead of requesting a file, sitting and twiddling your thumbs, getting pissed off waiting for it to come in, you just 'subscribe' to the source's 'channel', then get on with other stuff
14:08 < deer> <aum> konspire2b.sf.net
14:08 < jrandom> aum> but isn't that incredibly innefficient, since you've got to manage an overlay network (broadcast) for list of things available, then you've got to relay them?
14:09 < jrandom> wouldn't a direct swarming system be much more useful / efficient?
14:09 < deer> <ughabugha> Heh. That sounds promising for I2P.
14:09 < deer> <aum> jrandom: any examples of direct swarming?
14:09 < jrandom> wilde> oh, so like the cgiproxy on duck and janonymous's site?
14:09 < jrandom> aum> bittorrent
14:10 < deer> <ughabugha> aum: Did you mean http://konspire.sourceforge.net/?
14:10 < jrandom> where you get the torrent somewhere, and get content blocks directly from peers who have it
14:10 < deer> <aum> ughabugha: guess so :)
14:10 < mihi> argl... $me->brother removed the port forward for i2p...
14:10 < jrandom> d'oh
14:10 < deer> <aum> jrandom: is anyone currently trying bt/i2p?
14:11 < deer> <baffled> aum, have you had a close look at mnet?
14:11 < jrandom> aum> eco made some headway with i2psnark
14:11 < deer> <aum> i've had a look, but not a close look
14:11 < jrandom> (though he's mia at the moment)
14:12 < jrandom> hmm, mnet with eepsite metatrackers and human's i2p/twisted transport might work
14:12 < deer> <duck> heavy testing by janonymous and me seem to show that the current i2psnark problems are 50% caused by i2p and 50% by snark
14:12 < jrandom> duck> how recently were those tests?
14:12 < deer> <duck> last week
14:12 < jrandom> though i've got no qualms with potentially exploring other bt implementations
14:12 < jrandom> ah ok
14:13 < deer> <duck> about mnet, I _think_ that you'd first to fix mnet itself before you could make that working
14:13 < deer> <duck> so you might as wel fix freenet and use that
14:13 < jrandom> heh
14:13 < deer> <aum> fix freenet, ok! right after we bring in world peace ;p
14:13 < deer> <duck> but ask in #mnet @ freenode
14:13 < deer> <Pellinore> mnet=?
14:13 < deer> <Pellinore> Mute?
14:14 < jrandom> in that sense, perhaps an azureus mod for i2p might work?
14:14 < deer> <wilde> no, a market based p2p approach
14:14 < jrandom> pellinore - mnet.sf.net, a distributed data store without anonymity
14:14 < deer> <baffled> Actually, I'm using mnet quite reliably on about five machines.
14:14 < jrandom> right, the mojonation followon
14:14 < deer> <baffled> I can't use freenet reliably on one machine.
14:14 < deer> <duck> baffled: 0.6 or 0.7?
14:14 < deer> <duck> (0.7 is with twisted iirc)
14:16 < deer> <Pellinore> jrandom -- thanks.
14:16 < deer> <Pellinore> You can't use Freenet reliably on any machine.
14:17 < deer> <baffled> 0.6.[23].
14:17 < deer> <Pellinore> That is, among other reasons, why we are here. :)
14:17 < deer> <aum> i find that entropy works well... eventually!
14:17 < jrandom> i don't know, i still think freenet might be a good base to work from for the i2p DHT (when we can cut out most of the code and keep the data store / SSK/CHK stuff)
14:18 < jrandom> for file sharing, we should learn from the filesharing crowd what works best
14:18 < deer> <aum> but since my linuxworld article on entropy, there's gazillions of entropy nodes now, and the net has taken on some freenet performance characteristics
14:18 < deer> <Pellinore> I like the basic layout and features of Freenet, it's just that the fucker doesn't work, especially if one is using a dialup connection.
14:18 < jrandom> e.g. DC clones, BT, [or what else do those crazy filesharing people use?]
14:19 < jrandom> heh aum, damn you ;)
14:19 < deer> <duck> plus there are the things that Newsbyte did identify about entropy...
14:19 < deer> <aum> it's weaker anonymity, for example?
14:19 < deer> <baffled> Right but there are instability issues with 0.7.
14:19 < deer> <baffled> I think this connection has gotten flakey again.
14:19 < jrandom> and security issues.  i think we can unfortunately pass on using entropy
14:21 < jrandom> but, erm, we're on discussion point 4, *web* architecture so for the moment lets jump back to that ;)
14:21 < deer> <aum> another mad-assed file-sharing idea - what about using nntp, with n people running linked nntpds, and just use one of those libs that breaks down files into b64 chunks and posts them, and libs to retrieve them?
14:22 < jrandom> NNTP would be really interesting - its reliable as fuck and time tested
14:22 < deer> <duck> linking the servers?
14:22  * jrandom would love to have an innd running with i2p ;)
14:23 < deer> <aum> and since i2p does the anonymity, there's no need for nntp to have it
14:23 < jrandom> right, the innd feed line could point at a local i2ptunnel proxy
14:23 < deer> <aum> and people with different servers can config the servers to cache their own choice of groups
14:23 < mihi> depending on how often they peer it would be possible to censor articles by creating message id collisions
14:23 < deer> <duck> (ever tried configuring innd?)
14:24 < jrandom> many times duck, but a loooong time ago
14:24 < deer> <aum> is innd hard to setup?
14:24 < deer> <duck> oh well, you are god
14:24 < jrandom> mihi> agreed - thats not a censorship proof distribution medium
14:24 < jrandom> aum> its a bitch
14:25 < jrandom> just like squid - its good at what it does, but we likely need something dirt simple (one click, hopefully) to bundle
14:25  * jrandom drags us back on topic
14:26 < deer> <aum> and yet another p2p/filesharing approach - i seem to recall seeing a p2p app that works via http, chaining http servers
14:26  * mihi guesses most users don't know how to set up a proxy in their brwoser...
14:26 < deer> <aum> sorry, what's the topic?
14:26 < jrandom> agenda item 4) web architecture ;)
14:26 < aum> as in, web servers within i2p?
14:26 < mihi> aum: yep
14:26 < jrandom> thats a good point mihi - a web system will want the basics (.bat, .sh scripts) for startup/shutdown
14:27 < jrandom> hmm, doesn't mozilla include a javascript url you can do to set the proxy?
14:27 < jrandom> e.g. could we have a config page on httptunnel to click "on"/"off"?
14:28 < jrandom> i realize we're not going to come to any decisions today about how the web functionality should work, but we should get some directions down
14:28 < aum> what's the problem with the current eepproxy setup?
14:29 < jrandom> e.g. filtering, inbound proxies (eeproxies), outbound servers (normal i2ptunnel server), outbound proxies (outproxies ala squid or tor-www)
14:29 < mihi> aum: it requires quite some skill both to provide and to request eepsites
14:29 < jrandom> also, the existing outproxy system sucks.
14:29 < jrandom> its wholely unscalable
14:29 < jrandom> we need something to allow/force distributing the outbound web request load across multiple outproxies
14:30 < mihi> how can users get these outproxies. config file (like in hosts.txt?)
14:30 < jrandom> and one reason why normal people would want to run outproxies is for plausible deniability - even if THEY are requesting "bad stuff", they can say "i2p did it"
14:31 < jrandom> thats one option mihhi
14:31 < mihi> jrandom: hehe
14:31 < jrandom> s/hh/h/
14:31 < aum> but doesn't eepproxy make 'direct' http connection to the requested server, ie as 'direct' as i2p connections are?
14:31 < deer> <wilde> . /castvote DHT ala Freenet
14:31 < mihi> aum: the problem are "normal" web urls.
14:31 < jrandom> ./castvote 3 developers x 1 month x 12h / day
14:32 < deer> * human added httptunnel support to the TunnelManager, btw
14:32 < deer> <human> s/httptunnel/httpclient/
14:32 < deer> <aum> what's that?
14:32 < deer> <aum> oh, http client support?
14:32 < deer> <human> aum: yes
14:32 < jrandom> right, we need to find a way to let people browse slashdot.org via i2p
14:32 < deer> <aum> so tunnelmgr now talks http?
14:32 < jrandom> nice1 human!
14:32 < jrandom> aum> remember the squid proxy?
14:33 < deer> <aum> yep
14:33 < deer> <wilde> jrandom: so 4 man-months roughly for a DHT?
14:33 < deer> <human> aum: yup: openhttpclient <port> [<outbound WWW proxy>]
14:33 < jrandom> wilde> i think thats reasonable, yes.
14:34 < deer> <aum> human: have you written it up anywhere?
14:35 < jrandom> aum> all it does is say "if !eepsite { send through $outboundWWWproxy } else {send to eepsite}"
14:35 < deer> <human> aum: i was going to commit, then i got stuck with a StreamingI2PTunnelServer bug...
14:36 < jrandom> a good short term solution would be a "outproxies.txt", ala hosts.txt
14:36 < deer> <aum> human: and what exactly does 'openhttpclient <port> [<outbound WWW proxy>]' do?
14:36 < jrandom> though we should start thinking about medium and long term solutions
14:37 < deer> <human> human: will open a proxy listening for connections, that will redirect to WWW-proxy all the stuff that goes to URLS not ending with .i2p
14:38 < deer> <Pellinore> Now that's interesting.
14:38 < deer> <aum> human: ahh, nice, so you split off a thread within tunnelmgr?
14:38 < deer> <human> human: i.e. you can use it to browse both eepsite and the normal web
14:38 < deer> <human> human: yes
14:38 < deer> <human> s/human/aum/ :-)
14:39 < deer> <aum> slightly outside the 'brief' of tunnelmgr, but hey, there's no other place more appropriate in the i2p code - good job d00d
14:39 < deer> <aum> human: so you talk python *and* java? is that damaging your brain?
14:39 < deer> <human> aum: i did it to avoid launching yet another JVM for the EepProxy
14:40 < jrandom> (well, the code is implement in i2ptunnel's httpclient, human just recently exposed it through tunnelmanager as well)
14:40 < deer> <aum> yes, always good to keep the jvm instances down to a minimum
14:40 < jrandom> ((and imho httpclient is exactly where it should go ;)
14:40 < jrandom> (((until mihi's NextGen httpclient [httptunnel] is out)))
14:41 < deer> <aum> is httpclient in cvs, such that it'll build for me as part of i2p update/build?
14:41 < jrandom> yes, eepProxy uses httpclient
14:42 < deer> <aum> *man this is so schizophrenic - i've got 3 xchat sessions open (irc.duck.i2p,iip,freenode)) 
14:42 < jrandom> :)
14:42 < deer> <aum> wicked latency on irc.duck.i2p
14:42 < jrandom> ok, so no closure on the web architecture today, obviously, but worthwhile discussion
14:43 < jrandom> yeah aum, 15s or so for me
14:43 < jrandom> anything else on the web architecture for now, or should we move on to the 5) ??? open discussion section?
14:43 < deer> * human is thinking about an I2PSocksTunnel
14:44 < jrandom> yikes, now that'd be cool
14:44 < deer> <human> (well, maybe it belongs to 5)
14:44 < deer> <aum> socks? is there a way to 'shim' non-socks-enabled clients through to a socks interface?
14:44 < deer> <human> aum: apt-get install tsocks :-)
14:45 < aum> web discussion - one last thing - what about possibly forking /patching an existing web client
14:45 < mihi> aum: sockscap for windwos
14:45 < jrandom> aum> scary.  very powerful, but scary.
14:45 < jrandom> [i'd hate to have to maintain that]
14:45 < aum> even for now, a brain-dead browser like dillo
14:46 < jrandom> [[though it could be made 'uber secure', etc.  but still, very, very scary]]
14:46 < aum> or better, the browser control in wxwindows, it's multiplatform
14:46  * jrandom reminices about the orignial flinks, when it had a built in freesite browser
14:47 < aum> but then again, n00bs will whinge if they can't surf their usual m$-specific-javascript-infested sites
14:47 < jrandom> right aum, and so will hackers if it doesnt support the latest standards compliant code
14:47 < aum> hey, we should ask Microsoft for the source to IE6, then patch it ;p
14:47 < jrandom> building a browser == good way to waste thousands of man-hours
14:47 < jrandom> heh
14:47 < deer> * human is quite happy using privoxy
14:48 < aum> maybe they might toos in ie6 source as part of the European punitive settlement
14:48 < deer> <human> (http://www.privoxy.org/)
14:48 < aum> s/toos/toss/
14:48 < jrandom> human> how would that fly for both sides of the proxy?
14:48 < jrandom> e.g. we'll want the content filtered locally, not at the outbound endpoint
14:49 < deer> <human> jrandom: users could be encouraged to install it
14:49 < jrandom> (but the outbound endpoint will want to filter some content to avoid abuse, etc)
14:49 < deer> <human> jrandom: or it may be part of the default I2P installation
14:49 < aum> what if a DWP (distrib web proxy) was using a DHT for its cache?
14:49 < jrandom> encourage == only geeks.  bundle :)
14:49 < jrandom> that'd be Good aum
14:49 < deer> <human> jrandom: eheheh, agreed :-)
14:49 < deer> <human> jrandom: privoxy also runs on windogs, btw
14:50 < jrandom> word.  yeah, we need some sort of content filtering - privoxy, muffin, whatever.
14:50 < deer> <wilde> long meeting...
14:50  * jrandom takes the hint..
14:51 < deer> <Pellinore> wilde: Much to be said.
14:51 < jrandom> anyone else have anything they want to bring up?  we always have the mailing list for further things
14:51 < deer> <Pellinore> And much to be done of course.
14:51 < deer> <Pellinore> I have a couple of small questions.
14:51 < aum> could we fork privoxy and 1) make it work over i2p, 2) make it use DHT for caching?
14:51 < deer> <Pellinore> But they are as easily taken up privately.
14:51 < jrandom> pellinore> whats up?
14:51 < deer> <Pellinore> Nada, sorry I said anything.
14:51 < jrandom> aum> most likely we wouldnt need to fork
14:52 < deer> <Pellinore> I'll talk to you about it privately, or duck, at another time.
14:52 < deer> <Pellinore> Not really dev-specific stuff.
14:52 < deer> <duck> 10+16+7=33 manhours wasted on this one-hour overtime :)
14:52 < jrandom> but building a DHT is a lot of effort.  wholely incredibly worthwhile
14:52 -!- Irssi: #i2p: Total of 10 nicks [0 ops, 0 halfops, 0 voices, 10 normal]
14:52  * aum goes again to visit infoanarchy.org wiki pages on DHTs
14:52 < jrandom> there are 16 people on iip?
14:53 < deer> <human> aum: no need to fork, just: web browser <-> privoxy <-> httpclient <-> i2p <-> outbound proxy <-> www.pr0n.com
14:53 < deer> <wilde> a generic DHT that would work outside I2P too, and that allows other binding than http
14:53 < jrandom> aum> check out the link duck added to the i2p wiki, listing various ones
14:54 < deer> <human> aum: you can configure privoxy to make it connect to another HTTP/socks proxy (that's how my I2P-to-tor privoxy works)
14:54 < deer> <duck> (http://www.bamboo-dht.org/)
14:54 < aum> not sure i like the idea of a dht working outside i2p - the best dht is one without anonymity (and the anonymity overhead) that can work most optimally within i2p
14:54 < jrandom> hrm duck, what happened to that list of 'em?
14:54 < deer> <duck> aum: easier to test
14:55 < deer> <duck> jrandom: some commie did remove it I guess
14:55 < jrandom> heh
14:56 < jrandom> google++ : http://www.etse.urv.es/~cpairot/dhts.html
14:56 < jrandom> (not the same page, but interesting)
14:56 < jrandom> oh, here's the page - http://himalia.it.jyu.fi/ffdoc/storm/pegboard/available_overlays--hemppah/peg.gen.html
14:57 < jrandom> but yes, a DHT that doesnt try to implement anonymity, plus a DHT that supports both CHK-style and SSK style content would be best
14:58 < jrandom> (SSK style not being strictly necessary, but damn it would be really useful)
14:58 < jrandom> but, anyway
14:58 < jrandom> anyone got anything else they want to bring up?
14:59 < deer> <duck> tomorrow is St. Patrick's Day
14:59 < deer> <wilde> topic 5) ?
14:59 < deer> <duck> so all drink irish beer
14:59 < jrandom> good point
14:59 < deer> <Pellinore> TOmorrow is both the anniversary of my current relationship, and of my second marriage.
14:59  * jrandom takes note to avoid irish pubs tomorrow
15:00 < jrandom> oh, congrats pellinore :)
15:00 < jrandom> wilde> we're on 5) ???
15:01 < jrandom> (and about to be on 6) [baf])
15:01  * jrandom will be coming to iip momentarily [if i can]
15:01  * jrandom winds up
15:01  * jrandom *baf*s the meeting closed