81 lines
6.8 KiB
HTML
81 lines
6.8 KiB
HTML
{% extends "_layout.html" %}
|
|
{% block title %}I2P Development Meeting 204{% endblock %}
|
|
{% block content %}<h3>I2P dev meeting, March 27, 2007</h3>
|
|
<div class="irclog">
|
|
<p>16:02 < jrandom> 0) hi</p>
|
|
<p>16:02 < jrandom> 1) Net status</p>
|
|
<p>16:02 < jrandom> 2) zzz's NTCP/SSU proposals</p>
|
|
<p>16:03 < jrandom> 3) Syndie dev status</p>
|
|
<p>16:03 < jrandom> 4) DNS/registrar status</p>
|
|
<p>16:03 < jrandom> 5) ???</p>
|
|
<p>16:03 < jrandom> 0) hi</p>
|
|
<p>16:03 * jrandom waves</p>
|
|
<p>16:03 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-March/001342.html</p>
|
|
<p>16:04 < jrandom> jumping into 1) net status</p>
|
|
<p>16:04 < jrandom> things seem pretty good, and as mentioned there's more research to do regarding the latest changes</p>
|
|
<p>16:05 <+Complication> I wanted to complain a bit about IRC connectivity (everything else seems decent enough), but this last day, I've only had about 6 disconnects, which ain't so bad</p>
|
|
<p>16:05 < cervantes> /mute Complication</p>
|
|
<p>16:05 < jrandom> heh</p>
|
|
<p>16:05 <+Complication> :D</p>
|
|
<p>16:06 <+Complication> Tunnel build success is very nice, though</p>
|
|
<p>16:06 * Complication checks again, just in case</p>
|
|
<p>16:06 < jrandom> yeah i've seen some discon churn (though tbh, i read my backlog with a grep -v -\!- so never see the discons ;)</p>
|
|
<p>16:06 < cervantes> there have been various ISP cockups recently on the irc front - postman is looking into alternative hosting arrangements</p>
|
|
<p>16:06 < jrandom> tunnel build rates on the stats have made an upturn, though seem generally in line with the cycles up on stats.i2p</p>
|
|
<p>16:06 < cervantes> hopefully we can get some better network redundancy</p>
|
|
<p>16:06 < jrandom> ah ok cervantes </p>
|
|
<p>16:07 * jrandom would offer to help w/ dev.i2p.net, but i dont remember the last time the load was under 4 on it</p>
|
|
<p>16:08 < jrandom> ok, anyone have anything else to bring up re: net status?</p>
|
|
<p>16:10 < jrandom> if not, hopping over to 2) zzz's NTCP/SSU proposals</p>
|
|
<p>16:10 < jrandom> zzz doesn't seem to be around atm, and i left my syndie posts responding to the thread at home (d'oh)</p>
|
|
<p>16:11 < jrandom> in any case, post up your thoughts in zzz's blog (or read there for more info)</p>
|
|
<p>16:11 < jrandom> anyone have anything to discuss regarding that here now though?</p>
|
|
<p>16:12 <+Complication> Well, I personally wrote a reply there, expressing concern about too great reliance on UDP (since for me personally, UDP had rather high retransmission rates)</p>
|
|
<p>16:12 < jrandom> aye</p>
|
|
<p>16:12 <+Complication> I thougt, however, about one approach...</p>
|
|
<p>16:12 <+Complication> Currently the bids are fully deterministic (as opposed to probabilistic with a random component) right?</p>
|
|
<p>16:13 < jrandom> aye, fully deterministic</p>
|
|
<p>16:13 <+Complication> I was wondering if there would be any benefit (in the sense of avoiding extremes) in making them have a probability component</p>
|
|
<p>16:14 <+Complication> As in "60% chance of getting NTCP, 40% chance of getting SSU"</p>
|
|
<p>16:14 <+Complication> (assuming no prior data - if prior failure / success data would be present, that would probably need to skew the probability in favour of the better-performing transport for that link)</p>
|
|
<p>16:15 < jrandom> well, it depends on what one is hoping to achieve - from my understanding of zzz's proposal, the aim is to use ssu whenever possible</p>
|
|
<p>16:15 <+Complication> (assuming of course that both transports are usable for a given link - sometimes they certainly aren't)</p>
|
|
<p>16:15 < jrandom> randomizing it would't help with that, though would offer more room to get data on both transports in the wild</p>
|
|
<p>16:16 <+Complication> Just a thought on one possible way of trying to strike a balance between them ('cause if one always bids higher, routers likely won't "experiment" much)</p>
|
|
<p>16:19 < jrandom> 'tis a method we could use to gather more data, worth keeping in mind</p>
|
|
<p>16:19 < jrandom> ok, as mentioned, post on up to that thread for more stuff :)</p>
|
|
<p>16:20 < jrandom> jumping on over to 3) Syndie dev status</p>
|
|
<p>16:20 < jrandom> i dont have much to add beyond whats in the mail</p>
|
|
<p>16:20 < jrandom> anyone have any questions/comments/concerns?</p>
|
|
<p>16:21 <+Complication> Not yet. :)</p>
|
|
<p>16:22 < jrandom> hehe</p>
|
|
<p>16:22 * Complication entertains a hope of helping out more, either on the I2P or Syndie front, but I really need to get that webcache thingy out of the door first</p>
|
|
<p>16:22 < jrandom> w3rd, looking forward to both :)</p>
|
|
<p>16:24 < jrandom> ok lets skip past 4 and jump to 5) ???</p>
|
|
<p>16:25 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
|
|
<p>16:26 < TrevorReznik> is there any interest in a hashcash generator for i2p?</p>
|
|
<p>16:26 < TrevorReznik> as in through the browserinterface.</p>
|
|
<p>16:26 < TrevorReznik> i thought about that as kind of way to eliminate possible DoS scenarios inside i2p.</p>
|
|
<p>16:27 < jrandom> hmm, in javascript or c/java?</p>
|
|
<p>16:27 < jrandom> i think there are a few hashcash generators out there</p>
|
|
<p>16:27 < TrevorReznik> in java.</p>
|
|
<p>16:28 <+Complication> well, some research into hashcash schemes is likely to be needed at some point</p>
|
|
<p>16:28 < TrevorReznik> www.hashcash.org has some i think.</p>
|
|
<p>16:28 < TrevorReznik> they are an initiative to establish it for email clients as antispam thing.</p>
|
|
<p>16:28 <+Complication> perhaps not research in a proper sense, but in an implementation and best practise sese</p>
|
|
<p>16:28 <+Complication> =sense</p>
|
|
<p>16:28 < TrevorReznik> they have a collection of implementations in a multitude of languages.</p>
|
|
<p>16:28 < TrevorReznik> there are 2 java classes and at least one applet there, though i dont know the exact license parameters as of now.</p>
|
|
<p>16:30 <+Complication> places which could use it: 1) nym registration in Syndie 2) name registration in I2P</p>
|
|
<p>16:30 <+Complication> 3) email, obviously</p>
|
|
<p>16:30 * TrevorReznik agrees.</p>
|
|
<p>16:30 <+Complication> 4) in less optimistic scenarios, ordinary messages in Syndie</p>
|
|
<p>16:31 <+Complication> on the I2P network level itself...</p>
|
|
<p>16:31 <+Complication> hmm</p>
|
|
<p>16:31 < jrandom> its possible to embed them into tunnel creation mesages, but we're already hosed on that cpu front as it is ;)</p>
|
|
<p>16:39 < jrandom> ok, anyone have anything else for the meeting?</p>
|
|
<p>16:41 < jrandom> if not</p>
|
|
<p>16:41 * jrandom winds up</p>
|
|
<p>16:41 * jrandom *baf*s the meeting closed</p>
|
|
</div>
|
|
{% endblock %} |