I2P dev meeting, March 27, 2007

Quick recap

  • Present:

cervantes, Complication, jrandom, TrevorReznik,

Registo Completo do IRC

16:02 < jrandom> 0) hi
16:02 < jrandom> 1) Net status
16:02 < jrandom> 2) zzz's NTCP/SSU proposals
16:03 < jrandom> 3) Syndie dev status
16:03 < jrandom> 4) DNS/registrar status
16:03 < jrandom> 5) ???
16:03 < jrandom> 0) hi
16:03  * jrandom waves
16:03 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-March/001342.html
16:04 < jrandom> jumping into 1) net status
16:04 < jrandom> things seem pretty good, and as mentioned there's more research to do regarding the latest changes
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
16:05 < cervantes>  /mute Complication
16:05 < jrandom> heh
16:05 <+Complication> :D
16:06 <+Complication> Tunnel build success is very nice, though
16:06  * Complication checks again, just in case
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 ;)
16:06 < cervantes> there have been various ISP cockups recently on the irc front - postman is looking into alternative hosting arrangements
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
16:06 < cervantes> hopefully we can get some better network redundancy
16:06 < jrandom> ah ok cervantes 
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
16:08 < jrandom> ok, anyone have anything else to bring up re: net status?
16:10 < jrandom> if not, hopping over to 2) zzz's NTCP/SSU proposals
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)
16:11 < jrandom> in any case, post up your thoughts in zzz's blog (or read there for more info)
16:11 < jrandom> anyone have anything to discuss regarding that here now though?
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)
16:12 < jrandom> aye
16:12 <+Complication> I thougt, however, about one approach...
16:12 <+Complication> Currently the bids are fully deterministic (as opposed to probabilistic with a random component) right?
16:13 < jrandom> aye, fully deterministic
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
16:14 <+Complication> As in "60% chance of getting NTCP, 40% chance of getting SSU"
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)
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
16:15 <+Complication> (assuming of course that both transports are usable for a given link - sometimes they certainly aren't)
16:15 < jrandom> randomizing it would't help with that, though would offer more room to get data on both transports in the wild
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)
16:19 < jrandom> 'tis a method we could use to gather more data, worth keeping in mind
16:19 < jrandom> ok, as mentioned, post on up to that thread for more stuff :)
16:20 < jrandom> jumping on over to 3) Syndie dev status
16:20 < jrandom> i dont have much to add beyond whats in the mail
16:20 < jrandom> anyone have any questions/comments/concerns?
16:21 <+Complication> Not yet. :)
16:22 < jrandom> hehe
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
16:22 < jrandom> w3rd, looking forward to both :)
16:24 < jrandom> ok lets skip past 4 and jump to 5) ???
16:25 < jrandom> anyone have anything else they want to bring up for the meeting?
16:26 < TrevorReznik> is there any interest in a hashcash generator for i2p?
16:26 < TrevorReznik> as in through the browserinterface.
16:26 < TrevorReznik> i thought about that as kind of way to eliminate possible DoS scenarios inside i2p.
16:27 < jrandom> hmm, in javascript or c/java?
16:27 < jrandom> i think there are a few hashcash generators out there
16:27 < TrevorReznik> in java.
16:28 <+Complication> well, some research into hashcash schemes is likely to be needed at some point
16:28 < TrevorReznik> www.hashcash.org has some i think.
16:28 < TrevorReznik> they are an initiative to establish it for email clients as antispam thing.
16:28 <+Complication> perhaps not research in a proper sense, but in an implementation and best practise sese
16:28 <+Complication> =sense
16:28 < TrevorReznik> they have a collection of implementations in a multitude of languages.
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.
16:30 <+Complication> places which could use it: 1) nym registration in Syndie 2) name registration in I2P
16:30 <+Complication> 3) email, obviously
16:30  * TrevorReznik agrees.
16:30 <+Complication> 4) in less optimistic scenarios, ordinary messages in Syndie
16:31 <+Complication> on the I2P network level itself...
16:31 <+Complication> hmm
16:31 < jrandom> its possible to embed them into tunnel creation mesages, but we're already hosed on that cpu front as it is ;)
16:39 < jrandom> ok, anyone have anything else for the meeting?
16:41 < jrandom> if not
16:41  * jrandom winds up
16:41  * jrandom *baf*s the meeting closed