i2p.www/www.i2p2/pages/meeting186.html

{% extends "_layout.html" %}
{% block title %}I2P Development Meeting 186{% endblock %}
{% block content %}<h3>I2P dev meeting, October 24, 2006</h3>
<div class="irclog">
<p>16:03 &lt; jrandom&gt; 0) hi</p>
<p>16:03 &lt; jrandom&gt; 1) Net status</p>
<p>16:03 &lt; jrandom&gt; 2) Syndie dev status</p>
<p>16:03 &lt; jrandom&gt; 3) ???</p>
<p>16:03 &lt; jrandom&gt; 0) hi</p>
<p>16:03  * jrandom waves</p>
<p>16:03  * Complication stumbles to somewhere within reach of keyboard (week's beginning was hell, but it's over now)</p>
<p>16:04 &lt; jrandom&gt; (hooray to hellish beginnings!)</p>
<p>16:04 &lt; jrandom&gt; weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-October/001315.html</p>
<p>16:04 &lt;+Complication&gt; Hello</p>
<p>16:05 &lt; jrandom&gt; while y'all read the (short) notes, lets jump to 1) Net status</p>
<p>16:05  * jrandom has been connected to freshcoffee for 3 days now w/out discon, and it looks like both of the irc servers have a good number of users on them</p>
<p>16:06 &lt; jrandom&gt; stats.i2p is back too, and the tunnel success rate has been doing some odd jumps, but generally in good shape too</p>
<p>16:06 &lt; jrandom&gt; (though still in the 20-30 range)</p>
<p>16:06 &lt; jrandom&gt; ((which is much better than 5-10, but much worse than 60-80))</p>
<p>16:07 &lt; jrandom&gt; ok, anyone have anything to bring up for 1) net status?</p>
<p>16:08 &lt;+Complication&gt; Similar here, but no extra-persistent connections</p>
<p>16:08 &lt;+tethra&gt; other than applause, nothing from me!</p>
<p>16:08 &lt;+Complication&gt; I just wanted to drop a little line related to NTP issues</p>
<p>16:09 &lt;+Complication&gt; Basically, on Sunday, Oct 29, some times zones will jump off dailight saving time</p>
<p>16:09 &lt; jrandom&gt; (its going to suck)</p>
<p>16:10 &lt;+Complication&gt; I personally hope it doesn't cause anyone any problems, but I'm not well versed enough in NTP to be sure</p>
<p>16:10 &lt;+Complication&gt; So, just in case the recent NTP server sanity check (added with version .26) should inconvenience someone that night...</p>
<p>16:11 &lt;+Complication&gt; ...I thought it'd be better if I mentioned the configuration key using which it can be disabled (if need should exist)</p>
<p>16:11 &lt;+Complication&gt; (so folks who read status notes would know)</p>
<p>16:12 &lt;+Complication&gt; Disabling it can be done by entering the line "router.clockOffsetSanityCheck=false" into http://localhost:7657/configadvanced.jsp</p>
<p>16:12 &lt;+Complication&gt; But as mentioned, I do hope nobody needs that</p>
<p>16:13 &lt;+Complication&gt; It will be interesting to watch and see how the network behaves that night, though, as different time zones start switching</p>
<p>16:13 &lt;+Complication&gt; I'll certainly observe, in hope that if any anomaly is seen, perhaps it can be fixed by Spring :D</p>
<p>16:14 &lt; jrandom&gt; the minute-of will probably be pretty jumpy, but should heal shortly</p>
<p>16:14 &lt;+Complication&gt; ...and that's all I had. :)</p>
<p>16:14 &lt; jrandom&gt; but, hopefully it'll work out, and if not, as you say, there's spring :)</p>
<p>16:14 &lt; bar&gt; and should things indeed b0rk, there were two possible suggestions for future improvement that surfaced in the chat the other day:</p>
<p>16:15 &lt; bar&gt; "prevent skewed routers from forming subnets by handing over control to NTP if peers &lt; some number"</p>
<p>16:15 &lt; bar&gt; ...and "do not delete floodfill peer router infos from netdb if there are too few of them"</p>
<p>16:15 &lt; jrandom&gt; aye</p>
<p>16:16 &lt;+Complication&gt; Indeed, adjusting the required number of data points (available peer clock skews) which are required to deem peer skew measurements reliable</p>
<p>16:16 &lt;+Complication&gt; (oops, some redundancy in my last sentence)</p>
<p>16:17 &lt;+Complication&gt; ...and yes, the floodfill check. I take that no similar check exists currently?</p>
<p>16:18 &lt; jrandom&gt; right</p>
<p>16:18 &lt;+Complication&gt; Seems like some people, sometimes, either with luck or magic, may be managing to lose track of floodfill peers</p>
<p>16:19 &lt; jrandom&gt; that should certainly be remedied</p>
<p>16:19 &lt; jrandom&gt; (it hit some folks the other day, when one of 'em was null routed)</p>
<p>16:20 &lt; jrandom&gt; (if #floodfill == 0, perhaps randomly treat a few as floodfill)</p>
<p>16:20 &lt;+Complication&gt; If that's doable, possible also</p>
<p>16:21 &lt;+Complication&gt; Though, perhaps doing that in addition to keeping at least 2 (or something like that) floodfill peers would be a doubly safe bet</p>
<p>16:22 &lt; jrandom&gt; aye</p>
<p>16:25 &lt; jrandom&gt; ok, anyone have anything else for 1) net status?  or shall we move on over to 2) syndie dev status?</p>
<p>16:25 &lt; badger&gt; re irc stability: seeing much much much fewer reconnects at the server end.</p>
<p>16:25 &lt; badger&gt; you could almost call it a service :)</p>
<p>16:26 &lt; jrandom&gt; :)</p>
<p>16:28 &lt; jrandom&gt; ok, jumping on to 2) syndie dev status</p>
<p>16:28 &lt; jrandom&gt; lots of progress here, as mentioned in the status notes</p>
<p>16:28 &lt; jrandom&gt; there's also been a bunch of discussion on it here over the last few days</p>
<p>16:28 &lt; jrandom&gt; anyone have anything they want to bring up on that front?</p>
<p>16:30 &lt;@cervantes&gt; install something other than mspaint</p>
<p>16:30 &lt; jrandom&gt; heh</p>
<p>16:30 &lt; jrandom&gt; well, there's value in using *ugly* things to sketch - limits expectations</p>
<p>16:31 &lt;+fox&gt; &lt;HotTuna&gt; the links in the forumpost seem to be down ... some are anyway..</p>
<p>16:31 &lt;@cervantes&gt; I think that's mentioned in the posts</p>
<p>16:31 &lt;+fox&gt; &lt;HotTuna&gt; oh. . sorry</p>
<p>16:31 &lt; jrandom&gt; hottuna: they're mirrored @ dev.i2p.net/~jrandom/mockup/</p>
<p>16:31 &lt;@cervantes&gt; some should be mirrored further down</p>
<p>16:32 &lt;+Complication&gt; One question: so, do you think it's easier to (safely) implement limited HTML from ground up, without picking apart some web browser?</p>
<p>16:33  * jrandom just uploaded two more pics: dev.i2p.net/~jrandom/mockup/forum.png and blog.png (showing the discussion of the last few days regarding different ways to view a forum)</p>
<p>16:33 &lt;@cervantes&gt; most definitely easier to do that safely</p>
<p>16:33 &lt;+Complication&gt; (just being curious as to what's going in on the GUI side, having been somewhat unaware of it)</p>
<p>16:33 &lt; jrandom&gt; Complication: i've got nearly everything done for general formatting purposes already</p>
<p>16:33 &lt;@cervantes&gt; especially given the limited subset of html that syndie will support</p>
<p>16:34 &lt;+Complication&gt; Aha</p>
<p>16:34 &lt; jrandom&gt; (fonts, alignment, sizes, colors, images, links, lists (including nested), headers, paragraphs, html entities)</p>
<p>16:35 &lt; jrandom&gt; now, going in and doing divs for placement or tables requires substantially more work, but i'm not tackling that now</p>
<p>16:35 &lt;+Complication&gt; Sounds nice enough</p>
<p>16:36 &lt;@cervantes&gt; and of course the &lt;blink&gt; tag</p>
<p>16:36  * jrandom pelts cervantes with &dagger;</p>
<p>16:37 &lt;@cervantes&gt; ouch, skewered by an entity</p>
<p>16:37 &lt; jrandom&gt; we'll see though.  as it gets deployed and used, perhaps it'll be necessary to switch to a full blown html rendering engine</p>
<p>16:38  * jrandom wants the codebase to be as small as possible though, so there is less to debug and review for security and anonymity issues</p>
<p>16:39 &lt;+Complication&gt; Indeed, there are doubtless benefits to handling text/plain</p>
<p>16:40 &lt;+Complication&gt; (which hopefully only supports natural-language attacks ;P )</p>
<p>16:41 &lt;+Complication&gt; What are your opinions about the possibility of hashcash antispam measures? Too early to tell? Do you think they'd be easy to tack on later?</p>
<p>16:42 &lt;@cervantes&gt; well I guess using bbcode or wiki syntax would reduce the risk of markup injection in a full html engine</p>
<p>16:42 &lt;@cervantes&gt; *rendering engine</p>
<p>16:43 &lt; jrandom&gt; quite easy to tack on Complication - just a new public header (hashcalc'ed against the canonical syndie uri, verified on import, created on signing)</p>
<p>16:44  * Complication thought about some a few days back, but only lightly</p>
<p>16:44 &lt; jrandom&gt; the hashcash can be done at several levels too - per new channel (meta.syndie), per updated channel, or per post (perhaps even graduated against sizeof(post) or #msgs/day)</p>
<p>16:44 &lt;+Complication&gt; If one wanted to implement hashcash as proof of work, I wonder what the poster of the message would be best required to caclulate collisions against?</p>
<p>16:45 &lt;+Complication&gt; Aha, the uri... might be indeed</p>
<p>16:45 &lt;+Complication&gt; Oh, indeed</p>
<p>16:45 &lt;+Complication&gt; That's some things I didn't think about</p>
<p>16:48 &lt; jrandom&gt; cervantes: true enough</p>
<p>16:48 &lt; jrandom&gt; ok, anyone have anything else for 2) syndie dev status?</p>
<p>16:51 &lt; jrandom&gt; ok, if not, lets jump to 3) ???</p>
<p>16:51 &lt; jrandom&gt; anyone have anything else they want to bring up?</p>
<p>16:54 &lt; jrandom&gt; ok, if not...</p>
<p>16:54  * jrandom winds up</p>
<p>16:54  * jrandom *baf*s the meeting closed</p>
</div>
{% endblock %}