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