Well boys ’n girls, its Tuesday again!

Index:

  1. 0.3.4.3
  2. 0.3.5 and 0.4
  3. docs
  4. stasher update
  5. ???

1) 0.3.4.3

Well, as I’m you’ve all noticed, while the number of users on the network has stayed pretty steady, the performance has significantly degraded over the last few days. The source of this has been a series of bugs in the peer selection and message delivery code, exposed when there was a minor DoS last week. The result has been essentially everyone’s tunnels have been consistently failing, which has a bit of a snowball effect. So no, its not just you - the net has been horrid for the rest of us as well ;)

But the good news is we fixed the issues pretty quickly, and they’ve been in CVS since last week, but the network will still suck for people until the next release is out. On that note…

2) 0.3.5 and 0.4

While the next release will have all the goodies we’ve got planned for the 0.4 release (new installer, new web interface standard, new i2ptunnel interface, systray & windows service, threading improvements, bugfixes, etc), the way the last release degraded over time was telling. I want us to move more slowly on these releases, giving them time to deploy more fully and for kinks to show themselves. While the simulator can explore the basics, it doesn’t have any way of simulating the natural network issues we see on the live net (at least, not yet).

As such, the next release will be 0.3.5 - hopefully the last 0.3.* release, but perhaps not, if other issues arise. Looking back at how the network operated when I was offline in June, things started to degrade after about two weeks. As such, my thoughts are to hold off marking us up to the next 0.4 release level until we can sustain a high degree of reliability for at least two weeks. That doesn’t mean we won’t be doing work in the meantime, of course.

Anyway, as mentioned last week, hypercubus is chugging away at the new install system, dealing with me changing things around and requiring support for goofball systems. We should have things hammered out in the next few days to push out a 0.3.5 release in the next few days.

3) docs

One of the important thing we need to do during that two week “testing window” before 0.4 is to document like crazy. What I’m wondering is what things you feel our documentation is missing - what questions do you have that we need to answer? While I’d like to say “ok, now, go write those documents”, I’m realistic, so all I’m asking is if you can identify what those documents would discuss.

For instance, one of the docs I’m working on now is a revision of the threat model, which I’d now describe as a series of use cases explaining how I2P can serve different individual’s needs, including the functionality, the attackers that person is worried about, and how they defend themselves.

If you don’t think your question requires a full blown document to address, simply phrase it as a question and we can add it to the FAQ.

4) stasher update

Aum was by the channel earlier today with an update (while I peppered him with questions):

<aum> quick stasher update, with apologies for tomorrow's meeting:
<aum> infinite-level splitfiles working, have successfully
      inserted and retrieved large files
<jrandom> w00t
<aum> splitfile fragmentation/reassembly transparently occuring
      within stasher
<aum> freenet interface working
<jrandom> wow
<jrandom> so FUQID/FIW works?
<aum> use of fcp splitfile commands in freenet clients strictly
      forbidden (at this stage)
<aum> most clients such as fuqid/fiw should allow setting
      extremely large splitfile sizes, which should prevent them
      trying to talk splitfiles
<aum> if not, then i can dummy up something
<jrandom> r0x0r aum, that kicks ass!
<aum> hooks are in for detailed freenet key support
<jrandom> detailed freenet key support?
<aum> yes, specific chk@, ssk@, ksk@
<jrandom> ok great, so they're all verified @ each node, etc?
<aum> no - only verifiable by the requestor
<aum> my thinking is, given KSK@fred = 'mary',
<aum> to store as SHA1(SHA1("KSK@fred")) = E(mary), where key
      for E is SHA1("KSK@fred")
<aum> ie, crypto key is SHA1(uri), and kademlia key is
      SHA1(SHA1(uri))
<jrandom> hm
<aum> so a possessor of the URI can decyrpt, but owner of a
      datastore cannot decrypt (and therefore has plausible
      deniability)
<jrandom> well, ksks are inherently insecure, so thats no big
      loss, but what about ssk?
<deer> <detonate> those keys aren't very large
<aum> SSK as for freenet
<jrandom> so the SSKs are verified at each node?
<aum> except i'm looking to use same encryption over the top
<aum> not feasible to verify SSK at the target node
<jrandom> why not?  freenet does
<aum> well maybe it is feasible,
<aum> i guess i shouldn't be so lazy
<aum> i was trying to keep the kademlia and freenet layers
      separate
<jrandom> heh, you're not being lazy, there's a truckload of
      work here, and you're doing a great job
<aum> verifying on target node will cause some pathological
      couplings between the two layers, and force deviation
      from pure kademlia
<jrandom> i dont think its possible to do SSKs or CHKs
      securely without having the node validate the key
      properties
<aum> not correct
<aum> fred asks mary, 'gimme SSK@madonna'
<aum> mary sends back what she thinks is 'SSK@madonna'
<aum> fred tests it, barfs, then goes on to ask the next node
<aum> anyway, i MUST go - but am open to continuing discussion
      over email, or tomorrow
<aum> bbl guys
<jrandom> mallory floods the net with 'SSK@madonna' ==
      'sexDrugsRockNRoll'
<jrandom> l8r aum

So, as you can see, lots and lots of progress. Even if the keys are validated above the DHT layer, that’s wikked cool (imho). Go aum!

5) ???

Ok, thats all I’ve got to say (which is good, since the meeting starts in a few moments)… swing on by and say whatcha want!

=jr