I2P Dev Meeting - January 10, 2006

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