{% extends "_layout.html" %} {% block title %}I2P Development Meeting 163{% endblock %} {% block content %}

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

{% endblock %}