-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all, sorry for being late...

* Index:

1) 0.4
2) Capacity and overload
3) Website updates
4) I2PTunnel web interface
5) Roadmap and todo
6) ???

* 1) 0.4

As I'm sure you've all seen, the 0.4 release came out the other day
and overall, its going pretty well.  Its hard to believe it was 6
months since 0.3 came out (and a year since the 1.0 SDK was
released), but we've come a long way, and y'all's hard work,
enthusiasm, and patience has done wonders.  Congrats, and thanks!

Like any good release, as soon as it hit the door we found some
problems, and over the last few days we've been accumulating bug
reports and patching like mad (you can watch [1] the changes as
they're fixed).  We do still have a few more bugs left to squash
prior to pushing out the next rev, but that should be done in
the next day or so.

[1] http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD

* 2) Capacity and overload

We've seen some fairly skewed allocations of tunnels for the last few
releases, and while some of those are bug related (two of those fixed
since 0.4 came out), there is still a general algorithm question out
there - when should a router stop accepting more tunnels?

A few revs back, we added throttling code to reject requests to
participate in a tunnel if the router was overloaded (the local
message processing time exceeds 1s), and that has helped
substantially.  However, there are two aspects to that simple
algorithm that aren't addressed:
 = when our bandwidth is saturated, our local processing time may
   still be fast, so we'd continue to accept more tunnel requests
 = when a single peer participates in "too many" tunnels, when they
   fail, it hurts the network more.

The first issue is dealt with fairly easily by simply enabling the
bandwidth limiter (since bandwidth limiting slows down the message
processing time in accordance to the bandwidth delay).  The second
is more complicated, and both more research and more simulation is
necessary.  I'm thinking something along the lines of
probabalistically rejecting tunnel requests based on the ratio of
tunnels participating in and tunnels requested from the network,
including some base "kindness factor", setting P(reject) = 0 if
we're participating in less than that.

But as I said, more work and simulation is necessary.

* 3) Website updates

Now that we've got the new I2P web interface, pretty much all of our
old end user documentation is obsolete.  We need some help going
through those pages and updating them to describe how things are
now.  As duck and others have suggested, we need a new 'kickstart'
guide above and beyond the http://localhost:7657/ readme -
something to get people up and into the system.

In addition, our new web interface has plenty of room for integrating
context sensitive help.  As you can see on the bundled help.jsp,
"hmm. we should probably have some help text here."

It'd probably be great if we could add 'about' and/or
'troubleshooting' links to the different pages, explaining what
things mean and how to use them.

* 4) I2PTunnel web interface

To call the new http://localhost:7657/i2ptunnel/ interface "spartan"
would be an understatement.  We need to do a lot of work to get that
closer to a usable state - right now the functionality is technically
there, but you really need to know whats going on behind the scenes
to make sense of it.  I think duck may have some further ideas about
this to bring up during the meeting.

* 5) Roadmap and todo

I've been slacking on keeping the roadmap [2] up to date, but the
fact of the matter is, we've got some further revision ahead of us.
To help explain what I see as the "big problems", I've put together
a new task list [3], which goes into some detail on each.  I think
we should be fairly open at this point at reviewing our options and
perhaps reworking the roadmap.

One thing I've forgotten to mention on that todo list is that when
adding the lightweight connection protocol [4], we can include
(optional) autodetection of the IP address.  This may be 'dangerous'
(which is why it'll be optional), but it will dramatically reduce the
number of support requests we get :)

Anyway, those issues posted on the todo list are ones we've had
slated for various releases, and most certainly will not all be in
1.0 or even 2.0.  I've sketched out a few different possible
prioritization / releases, but I'm not hard set on those yet.
However, if people can identify other big things down the path, it'd
be much appreciated, as an unscheduled issue is always a pain in the
butt.

[2] http://www.i2p.net/roadmap
[3] http://www.i2p.net/todo
[4] http://www.i2p.net/todo#connection

* 6) ???

Ok, thats all I've got for now (good thing too, since the meeting
starts in a few minutes).  Swing on by #i2p on irc.freenode.net,
www.invisiblechat.com, or irc.duck.i2p at 9p GMT to chat further.

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBQT4ijhpxS9rYd+OGEQLGsQCg5nvwnBMw4nQaV6/d9loWZjWZhJkAoNxq
qS8j385jn3Xj4wIJCPimEX01
=jVx+
-----END PGP SIGNATURE-----