15:26 < jrandom> 0) hi
15:26 < jrandom> 1) Net status
15:26 < jrandom> 2) Throughput profiling
15:26 < jrandom> 3) Syndie blogs
15:26 < jrandom> 4) HTTP persistent connections
15:26 < jrandom> 5) I2Phex gwebcache
15:26 < jrandom> 6) ???
15:26  * jrandom waves
15:26 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-January/001247.html
15:27 < jrandom> (yeah, I know... we need a 7) One more thing...)
15:28 < jrandom> jumping on in to 1) Net status 
15:28 < jrandom> In general, seems the same ol' same ol', beyond whats in the mail.  
15:28 < jrandom> Anyone have anything they want to bring up about 1)?
15:30 < jrandom> ok, if not, moving on over to 2) Throughput profiling
15:31 < tethra> it sounds cool, but may i ask what the objective is?
15:31 < jrandom> find fast peers
15:31 < tethra> (forgive my lack of wit and tact)
15:31 < tethra> ah, cool.
15:32 < jrandom> basically, our old speed profiling wasn't that great (see last week's status notes for a summary), and this seems to be pretty good at finding peers that I know are fast
15:32 < jrandom> (I know they're fast because I've cheated and measured them with non-anonymous techniques)
15:33 < tethra> shocking! ;)
15:33 < jrandom> ((yes, someone could have been crazy and mounted attacks to confuse my measurements, but, well, I doubt it ;)
15:33 < tethra> haha
15:33 < tethra> sweet, so that should make client tunnels more likely to find a 'good' peer and presumably put the 'fast' peers under less pressure, then?
15:35 < tethra> s/'good'/fast/
15:35 < jrandom> yes to the former, but not really to the later - it won't reduce the pressure on them, but it will let people make more effective use of them
15:35 <@cervantes> I guess the folks with fast peers will have to hope the peer throttling is good enough to take the extra participation
15:36 < jrandom> e.g. rather than having $slow-->$fast-->$fast, it'll have $fast-->$fast-->$fast
15:36 < tethra> ah, i see
15:36 < jrandom> aye cervantes, I've been paying attention to the capacity profile as well, and its been doing the trick
15:36 <@cervantes> grand
15:37 < jrandom> the interplay between capacity and speed is important - peers are not considered fast if they are not high capacity, even if their speed is ranked higher than everyone else
15:37 <@cervantes> be interesting to see how it effects througput
15:37 < jrandom> (which is why 'fast' is just shorthand for 'fast and high capacity')
15:37 <@cervantes> +h
15:37 < jrandom> aye cervantes
15:39 < jrandom> ok, if there's nothing else on 2, lets jump on over to 3) Syndie blogs
15:40 < jrandom> I don't have much more to add beyond whats in the mail there
15:41 <@cervantes> it's looking swell
15:41 < tethra> i very much like where the blogs are going, personally. it seems to all be gravy, one might say.
15:41 < tethra> :D
15:41 <+Complication> Bit late, sorry.
15:42 < jrandom> cool, its similar to how it was originally, but I think the blog view has some promise
15:42 < jrandom> wb Complication, no worry, we've got logs :)
15:43 <+Complication> Reading scrollback right now :)
15:43 < jrandom> I do think there's a place for both views, I suppose it just depends on the user
15:43 < jrandom> (and the content, and the author)
15:45 < jrandom> one thing though is that the html aint that grand.  cervantes has been helping me revamp my very basic education to a more modern view, but there are lots of issues left
15:46 < jrandom> there will be continuing improvements to syndie's web interface, and if some html volunteer wanted to help out with formatting, design, css, cross browser issues, etc, it would be much appreciated
15:47 <@cervantes> other than having 2 opening <style> tags the code looks pretty clean ;-)
15:47 < jrandom> heh oops
15:48 <@cervantes> I think the emphasis will be on getting the styling clean and readable and perhaps designing some template alternatives
15:48 < jrandom> hmm
15:49 < jrandom> thats one thing I was thinking about for the blog view - it'd be easy to let people customize certain attributes (colors, fonts, sizes), but I'm not sure how much more
15:50 < jrandom> otoh, the blog view, like the thread view, is all just a template over the syndie archive
15:50 <@cervantes> well you certainly don't want to allow deployable templates
15:50 < jrandom> so the question is, a template for whom?
15:50 < jrandom> (what level of experience would those using the template require)
15:51 <@cervantes> I was thinking just a popup config option someone can choose for their blog
15:51 < jrandom> hmm?
15:51 <@cervantes> I want "Pony Look"
15:51 < jrandom> ah, ok
15:51 <@cervantes> so we ship syndie with a variety of skins
15:52 < jrandom> yeah, preset colors/font/etc
15:52 < jrandom> (and icons, etc)
15:52 < jrandom> thats one thing that hasn't really been implemented through the blog view yet
15:54 < jrandom> good idea on the simple theme chooser though, rather than some complex set of options
15:54 <@cervantes> an alternative would be someone can offer their own template presets as a download on their site - which could be saved into a theme folder
15:55 <@cervantes> it's up to the individual if they want to trust the blog author's custom skin
15:55 < jrandom> ... trust?
15:55 < jrandom> nothing in syndie will let you do unsafe html or css
15:55 < tethra> what of unsafe javascript/etc
15:55 < jrandom> the skins would be text files/config files/images, rather than jsp
15:55 < tethra> ?
15:56 < tethra> (page forwards to non-anonymous addresses with js, for instance?)
15:56 <@cervantes> it depends if a theme might also contain structural html changes 
15:56 <@cervantes> right ok
15:56 <@cervantes> well that would keep it nice an clean and simple
15:57 < jrandom> tethra: I'm... incredibly hesitant about javascript.  seen that new blog post today from default?
15:57 < jrandom> "I'm just curious: does it use AJAX? The page doesn't seem to update as a whole..."
15:57 < tethra> nein, i did not.
15:57 < tethra> i'd find a way to just shag any js that is used, personally.
15:58 < jrandom> since syndie is *local*, its insanely fast, and we don't need do worry about the same latency issues
15:58 < tethra> as i don't trust it as far as i can throw it.
15:58 < tethra> hmm :/
15:58 < jrandom> cervantes: aye, very simple - we could even do things like let people viewing a blog theme they like say "steal this theme"
15:59 <@cervantes> in theory you could provide a library of "safe" functions fo blog user - but by the time you remove everything that is unsafe from the average browser's implementation you're left with the "alert();" function
16:00 < jrandom> heh
16:00 < jrandom> (and you've got all those accessibility issues of javascript)
16:00 <+Complication> cervantes: mind you, alert() in an infinite loop can be bad :P
16:00  * jrandom is quite proud of syndie's lynx-friendliness
16:00 < tethra> lynx <3
16:02 < jrandom> ok, if there's nothing else on 3), lets jump on over to 4) HTTP persistent connections
16:02 < jrandom> I don't have anything to add beyond whats in the mail... zzz, you here?
16:02 <@cervantes> there are other ways of implementing a *spit* AJAX ui, like a mozilla extension
16:03 < jrandom> fire2pe++ :)
16:03 < jrandom> zzz doesn't seem to be around, so we'll probably have to wait for later for more info on 4)
16:03 <@cervantes> fire2pe is just a helper - syndilla is what you mean ;-)
16:03 < jrandom> lol
16:04 < jrandom> (and, the usb keychain version, syndog ;)
16:04 < jrandom> ok, moving on to 5) I2Phex gwebcache
16:05 < jrandom> Complication: p1ng
16:05 <+Complication> Well, since it would make integrating with the net easier...
16:06 <+Complication> ...I've recently worked on reviving the gwebcache code already in I2Phex
16:06 <+Complication> It's already doing some very limited things (like crash neatly) at this stage :)
16:06 <+Complication> Also pesters awup's webcache server with moderate success
16:07 < jrandom> lol nice
16:07 <+Complication> I have hope though, that eventually I'll get it reworked
16:07 <+Complication> (lots of it is currently meant to deal with IP addresses)
16:09 < jrandom> cool, good luck, and lemmie know if there's anything I can do to help
16:09 <+Complication> Will do :)
16:10 < jrandom> ok, anything else on 5) I2Phex gwebcache, or shall we mosey on over to 6) ???
16:11 < jrandom> consider us moseyed
16:11 < jrandom> anyone have anything else for the meeting?
16:11 <@cervantes> another cup of tea would be nice
16:12 < tethra> heheh
16:12 < Pseudonym> how's the roadmap?
16:12 < jrandom> no changes
16:12 < Pseudonym> what's left for 0.6.2?
16:13 < jrandom> all of the 0.6.2-related stuff
16:13  * jrandom ducks
16:14 < Pseudonym> :-P
16:14 <@cervantes> some bling bling
16:14 < Pseudonym> do we have a tentative date/timeline?
16:14 < jrandom> specifically, the new tunnel creation crypto and algorithms, the new peer selection strategies
16:14 < tethra> heheh
16:14 < jrandom> no dates and timelines (at least, not announced in meetings ;)
16:15 < Pseudonym> is there more to peer selection strategies than the throughput stuff you've been working on?
16:16 < jrandom> yes, these peer profiling changes are performance issues, not the anonymity related peer selection and ordering strategies
16:16 <+Complication> jrandom: do I remember correct... if I guess the tunnel creation crypto related to things discussed on the mailing list, during the talk about predecessor (and other) attacks?
16:17 < jrandom> yeah Complication 
16:17 <+Complication> s/related/relates
16:19 <+Complication> You're going to try making that fancy lil' datastructure work?
16:19 < jrandom> aye
16:20 < jrandom> (hence, 0.6.2 is not on the 2 week horizon ;)
16:20 <+Complication> Neat. Sounds interesting, I should probably read up about it
16:21 <+Complication> I hope it goes smoothly
16:21 < jrandom> it was only arm-waved around on the list, no spec digitized yet
16:21 < tethra> which neat datastructure is this, sorry?
16:21 <+Complication> Oh, and figured why the link (from the "moo" message) wouldn't work. :D It's freedomarchives.i2p (in the plural, with an "s" at end)
16:21 < jrandom> it'll be backwards incompatible, so smooth won't be its catchphrase, but hopefully won't hurt too much :)
16:21 < jrandom> ah bugger
16:22 < jrandom> tethra: a datastructure that doesn't exist yet for creating tunnels
16:22 < tethra> cool
16:22 < jrandom> (see the predecessor threads from november or so)
16:23 < tethra> what advantages/disadvantages will it have over the current one? (if there is a current one :o)
16:23 < jrandom> (see the predecessor threads from november or so) ;)
16:23 < tethra> ah, ok
16:23 <+Complication> IIRC, to make tunnel creation less transparent to observers
16:23 < tethra> ""
16:23 < tethra> ;)
16:23 < jrandom> but, its not a proposal, there is nothing on the table for 0.6.2 until all of the things prior to 0.6.2 are sorted.
16:23 < jrandom> once the things that should be working are working in the manner that we need them to work, then we move on.
16:24 < Pseudonym> other than fast peer selection, what's not working?
16:25 < jrandom> fast peer selection is a part of "good performance"
16:25 < jrandom> we /do/ have good performance, for an anonymous network, but not good enough to compete with non-anonymous networks
16:25 < jrandom> to compete, we've got to get better performance *and* provide functionality they can't get elsewhere
16:26 < jrandom> (anonymity does not sell)
16:26 < Pseudonym> is there more to it than fast peer selection?
16:27 < jrandom> through the last month or two, benchmarking different aspects of i2p, slow peer selection seems to be the smallest bottleneck.  what the next bottleneck will be is unknown.
16:27 < jrandom> (there have also been countless improvements at different points to improve performance)
16:27 < jrandom> (see http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD )
16:28 < Pseudonym> so... release of new peer selection this week? ;-)
16:28 < teal`c_> i2p feels good
16:29 < jrandom> Pseudonym: aye, new peer profile algorithm is in cvs and will be deployed this week with 0.6.1.9
16:30 < jrandom> ok, anyone have anything else for the meeting?
16:30 < Pseudonym> cool
16:31 < jrandom> if not...
16:31  * jrandom winds up
16:32  * jrandom *baf*s the meeting closed