kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

propagate from branch 'i2p.www' (head 3d12832c52f5971e9c757ba67426ca3d35538da5)

Browse Source 
to branch 'i2p.www.revamp' (head f123af1c64ee53f8863064570547a3d5049b2182)
This commit is contained in:
str4d
2013-03-01 21:47:43 +00:00
parent b8b487fe6e 719a125c25
commit e9a312c458
1292 changed files with 125070 additions and 57482 deletions
Download Patch File Download Diff File Expand all files Collapse all files

162
i2p2www/__init__.py Normal file
View File

@@ -0,0 +1,162 @@
from flask import Flask, request, g, redirect, url_for, abort, render_template, send_from_directory, safe_join
from flaskext.babel import Babel
from flask.ext.cache import Cache
from docutils.core import publish_parts
import os.path
import os
###########
# Constants
CURRENT_I2P_VERSION = '0.9.4'
CANONICAL_DOMAIN = 'www.i2p2.de'
BLOG_POSTS_PER_FEED = 10
BLOG_POSTS_PER_PAGE = 10
MEETINGS_PER_PAGE = 20
SUPPORTED_LANGS = [
'en',
'es',
# 'zh',
'de',
'fr',
# 'it',
# 'nl',
# 'ru',
'sv',
# 'cs',
# 'ar',
# 'el',
]
TEMPLATE_DIR = os.path.join(os.path.dirname(__file__), 'pages')
STATIC_DIR = os.path.join(os.path.dirname(__file__), 'static')
BLOG_DIR = os.path.join(os.path.dirname(__file__), 'blog')
MEETINGS_DIR = os.path.join(os.path.dirname(__file__), 'meetings/logs')
SITE_DIR = os.path.join(TEMPLATE_DIR, 'site')
MIRRORS_FILE = os.path.join(TEMPLATE_DIR, 'downloads/mirrors')
###################
# Application setup
app = application = Flask('i2p2www', template_folder=TEMPLATE_DIR, static_url_path='/_static', static_folder=STATIC_DIR)
app.debug = bool(os.environ.get('APP_DEBUG', 'False'))
babel = Babel(app)
cache = Cache(app, config={
'CACHE_DEFAULT_TIMEOUT': 600,
#'CACHE_TYPE': '', # See http://packages.python.org/Flask-Cache/#configuring-flask-cache
})
#################
# Babel selectors
@babel.localeselector
def get_locale():
# If the language is already set from the url, use that
if hasattr(g, 'lang'):
return g.lang
# otherwise try to guess the language from the user accept
# header the browser transmits. The best match wins.
return request.accept_languages.best_match(['en', 'es', 'zh', 'de', 'fr', 'it', 'nl', 'ru', 'sv', 'cs', 'ar'])
##########################
# Hooks - helper functions
def after_this_request(f):
if not hasattr(g, 'after_request_callbacks'):
g.after_request_callbacks = []
g.after_request_callbacks.append(f)
return f
###########################
# Hooks - url preprocessing
@app.url_value_preprocessor
def pull_lang(endpoint, values):
if not values:
return
g.lang=values.pop('lang', None)
@app.url_defaults
def set_lang(endpoint, values):
if not values:
return
if endpoint == 'static':
# Static urls shouldn't have a lang flag
# (causes complete reload on lang change)
return
if 'lang' in values:
return
if hasattr(g, 'lang'):
values['lang'] = g.lang
########################
# Hooks - before request
# Detect and store chosen theme
@app.before_request
def detect_theme():
theme = 'duck'
if 'style' in request.cookies:
theme = request.cookies['style']
if 'theme' in request.args.keys():
theme = request.args['theme']
# TEMPORARY: enable external themes
# TODO: Remove this (and the corresponding lines in global/layout.html
if theme[:7] == 'http://':
g.exttheme = theme
theme = 'duck'
if not os.path.isfile(safe_join(safe_join(STATIC_DIR, 'styles'), '%s/desktop.css' % theme)):
theme = 'duck'
g.theme = theme
@after_this_request
def remember_theme(resp):
if g.theme == 'duck' and 'style' in request.cookies:
resp.delete_cookie('style')
elif g.theme != 'duck':
resp.set_cookie('style', g.theme)
return resp
#######################
# Hooks - after request
@app.after_request
def call_after_request_callbacks(response):
for callback in getattr(g, 'after_request_callbacks', ()):
response = callback(response)
return response
##################
# Template filters
@app.template_filter('restructuredtext')
def restructuredtext(value):
parts = publish_parts(source=value, writer_name="html")
return parts['html_body']
################
# Error handlers
@app.errorhandler(404)
def page_not_found(error):
return render_template('global/error_404.html'), 404
@app.errorhandler(500)
def server_error(error):
return render_template('global/error_500.html'), 500
# Import these to ensure they get loaded
import templatevars
import urls

4
i2p2www/babel.cfg Normal file
View File

@@ -0,0 +1,4 @@
[python: **.py]
[jinja2: **/pages/**.html]
[jinja2: **/blog/**.rst]
extensions=jinja2.ext.autoescape,jinja2.ext.with_

92
i2p2www/blog/2004/07/13/status.html Normal file
View File

@@ -0,0 +1,92 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ev'nin' gang, its that time of the week
* Index
1) 0.3.2.1 and 0.3.2.2
2) Bandwidth limiting
3) Website
4) Python API
5) File sharing
6) ???
* 1) 0.3.2.1 and 0.3.2.2
So as y'all saw, the other day we came out with the 0.3.2.1 release,
but as I soon found out, there was a problem with the build which I
hadn't caught. Its a trivial little bug with the build scripts
that I added when trying to include support for the 1.5 JDK, but
its pretty fatal, as the jar files built are corrupt (though kaffe
handles them fine :)
So, thats been fixed in CVS and will be packaged in a new 0.3.2.2
release soon. I was going to push it yesterday but I came up with a
bit of a breakthrough when running the sim, so I'm following that
lead at the moment and will hold up the release until I get things
sorted.
That does mean however that the live net is going to be kinda shitty
until then (not fatal, but not fantastic).
* 2) Bandwidth limiting
There have been a lot of discussions on #i2p lately regarding the
bandwidth limiting algorithm used, and based on that I've updated the
code to allow for much smoother bandwidth usage, rather than the
bursty limiter from 0.3.2 and 0.3.2.1. This allows you to keep the
burst size the same as your rate, which is useful for people who have
high bandwidth contention. There will be some minor updates though
as the whole FIFO gets to be a bit of a problem in some environments
when the other side is rrreeeeaaallllyyy sssllloooowwww.
* 3) Website
Thanks to the hard work of duck and ugha, we've been making some
great progress on the site redesign - <a rel="nofollow" href="http://www.i2p.net/redesign/">http://www.i2p.net/redesign/</a>
There is still a lot of work to do, but duck and I agree that it'd be
best if we can replace the existing www.i2p.net/ page ASAP. So,
during the meeting we can discuss what is left to be done, snag
volunteers for various tasks, and draw that line in the sand.
Wilde also snagged an uncorrupted copy of the old website (yay!) so
we can use that to recover some data.
* 4) Python API
Connelly has posted up [1] some ideas for a socket style interface
for Python using SAM that could perhaps be implemented similarly
across other languages. The idea of mirroring the socket API has
value, both because of its usability and because it works the way
standard multithreaded / streaming apps work. There is a downside
though related to the old &quot;multithreaded and streaming&quot; vs &quot;event
based and messaging&quot; debate. Both have their merits, but I suppose
the key question is what do actual apps want? I dunno.
[1] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p/2004-July/000326.html">http://dev.i2p.net/pipermail/i2p/2004-July/000326.html</a>
* 5) File sharing
There have been some more discussions about file sharing on the
list and in the forum, as usual ;) No resolution yet from what I
can see but still some good dialog. But I suppose we'll see what
will be when we see what will be.
* 6) ???
I'm sure I've missed some things, and my mind is kind of scattered
at the moment, so swing on by tonight's meeting and we'll talk
about whats up.
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQPRNkxpxS9rYd+OGEQL4gwCgj5FAIxJLSz0kjLpc/difRWLfMqYAn3U9
c507IhMQP3WwejdCIyYRx7oX
=bul4
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/07/13/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-07-13
===============================
.. raw:: html
:file: blog/2004/07/13/status.html

147
i2p2www/blog/2004/07/20/status.html Normal file
View File

@@ -0,0 +1,147 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
1) 0.3.2.3, 0.3.3, and the roadmap
2) s/reliability/capacity/g
3) website updates
4) attacks and defenses
5) ???
* 1) 0.3.2.3, 0.3.3, and the roadmap
After the release of 0.3.2.3 last week, y'all have done a
great job of upgrading - we only have two holdouts now (one
at 0.3.2.2 and one way back at 0.3.1.4 :). Over the last
few days the network has been more reliable than usual -
people are staying on irc.duck.i2p for hours at a time,
larger file downloads are succeeding from eepsites, and
general eepsite reachability is fairly good. Since its
going well and I want to keep you on your toes, I decided
to change a few fundamental concepts and we'll have them
deployed in a 0.3.3 release in a day or two.
As a few people have commented about our schedule,
wondering whether we are going to hit the dates we had
up, I decided I should probably update the website to
reflect the roadmap I have in my palmpilot, so I did [1].
The dates have slipped and some items have been moved
around, but the plan is still the same as was discussed
last month [2].
0.4 will meet the four release criteria mentioned
(functional, secure, anonymous, and scalable), though
prior to 0.4.2, few people behind NATs and firewalls
will be able to participate, and prior to 0.4.3 there
will be an effective upper limit to the size of the
network due to the overhead of maintaining a large
number of TCP connections to other routers.
[1] <a rel="nofollow" href="http://www.i2p.net/redesign/roadmap">http://www.i2p.net/redesign/roadmap</a>
[2] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p/2004-June/000286.html">http://dev.i2p.net/pipermail/i2p/2004-June/000286.html</a>
* 2) s/reliability/capacity/g
Over the last week or so, people on #i2p have heard me
occationally rant about how our reliability rankings are
completely arbitrary (and the pain that has caused in
the last few releases). So we've gotten rid of the
concept of reliability completely, replacing it with a
measurement of capacity - &quot;how much can a peer do for
us?&quot; This has had ripple effects throughout the peer
selection and peer profiling code (and obviously on the
router console), but beyond that, there wasn't much
changed.
More info on this change can be seen on the revised
peer selection page [3], and when 0.3.3 is released,
y'all will be able to see the impact first hand (I've
been playing with it for the last few days, tweaking
some settings, etc).
[3] <a rel="nofollow" href="http://www.i2p.net/redesign/how_peerselection">http://www.i2p.net/redesign/how_peerselection</a>
* 3) website updates
Over the last week, we've been making a lot of progress
on the website redesign [4] - simplifying the nav, cleaning
up some key pages, importing old content, and writing up
some new entries [5]. We're almost ready to move the site
live, but there are still a few things that need to be
done.
Earlier today, duck went through the site and made an
inventory of pages we're missing, and after this
afternoon's updates, there are a few outstanding issues
that I hope we can either address or get some volunteers
to jump on -
* documentation:
hmm, do we need any content for this? or can we
have it just sit as a header with no page behind it?
* development:
I think this is in the same boat as &quot;documentation&quot; above
* news:
perhaps we can remove the 'announcements' page and put
that content here? or should we do as above and let
news be a simple heading, with an announcements page
below?
* i2ptunnel_services, i2ptunnel_tuning, i2ptunnel_lan:
We need someone to rewrite the 'how to set up an eepsite'
page, as well as include answers to the two most
frequently asked I2PTunnel questions (how to access it
through a LAN and how to configure its tunnels - answers
being: -e &quot;listen_on 0.0.0.0&quot; and
-e 'clientoptions tunnels.numInbound=1
tunnels.depthInbound=1', respectively)
Perhaps we can come up with some more comprehensive user
level I2PTunnel documentation?
* jvm:
er, I'm not sure about this page - is it 'how to tweak
the JVM for optimal performance'? do we *know*?
* config_tweaks:
other config parameters for the router (bandwidth limiting,
etc). could someone go through the router.config and
take a stab at what everything means? if anyone has any
questions, please let me know.
* more meeting logs:
mihi posted up an archive of some logs, perhaps a
volunteer can sift through those and post them up?
* perhaps we can update the meetings.html to be date
based and include a link to that week's status update
along with any release announcements preceding it?
Beyond that, I think the site is pretty close to being
ready to be moved live. Does anyone have any suggestions
or concerns along those lines?
[4] <a rel="nofollow" href="http://www.i2p.net/redesign/">http://www.i2p.net/redesign/</a>
[5] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2pwww/2004-July/thread.html">http://dev.i2p.net/pipermail/i2pwww/2004-July/thread.html</a>
* 4) attacks and defenses
Connelly has been coming up with a few new angles to try
to poke holes in the network's security and anonymity,
and in doing so he has come across some ways we can
improve things. While some aspects of the techniques
he described don't really match up with I2P, perhaps
y'all can see ways they can be expanded upon to attack
the network further? C'mon, give 'er a shot :)
* 5) ???
Thats about all I can remember before tonights meeting -
please feel free to bring up anything else I've
overlooked. Anyway, see y'all in #i2p in a few minutes.
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQP2FuBpxS9rYd+OGEQK0ugCgzqAfZtF2qQQdwRr/uVfibSIIM7wAoNZO
sxKqvaHlNppJCq/x/BzEWcxd
=uim5
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/07/20/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-07-20
===============================
.. raw:: html
:file: blog/2004/07/20/status.html

98
i2p2www/blog/2004/07/27/status.html Normal file
View File

@@ -0,0 +1,98 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
'lo all, time for the weekly rant session
* Index:
1) 0.3.3 &amp; current updates
2) NativeBigInteger
3) ???
* 1) 0.3.3
We pushed out the 0.3.3 release this past Friday and after a day
or two of pretty bumpy weather, it seems to be doing ok. Not as
good as 0.3.2.3, but I've usually been able to hang around on
irc.duck.i2p for 2-7h stints. However, as I've seen lots of
people having trouble, I fired up the logger and monitored in
detail what was up. Short answer is that we were simply using
more bandwidth than we need to, causing congestion and tunnel
failures (due to test messages timing out, etc).
I've spent the last few days back in the simulator, running a
series of heartbeats through a network to see what we can
improve, and we've got a whole slew of updates coming our way
based on that:
= netDb update to operate more efficiently
The existing netDb lookup messages are up to 10+KB, and while
successful replies are frequent, the unsuccessful replies
could be up to 30+KB (as both contained full RouterInfo
structures). The new netDb replaces those full RouterInfo
structures with the router's hash - turning 10KB and 30KB
messages into ~100 byte messages.
= throw out the SourceRouteBlock and SourceRouteReplyMessage
These structures were a remainder of an old idea but don't add
any value to the anonymity or security of the system. By
dropping them in favor of a simpler set of reply data points,
we cut the tunnel management message sizes dramatically, and
drop the garlic encryption time in half.
= removed some excess messages
The code was a bit 'chatty' during the tunnel creation, so the
unnecessary messages have been cut.
= reduced arbitrary padding
Some of the crypto code for the garlic routing was using fixed
padding based on some garlic routing techniques that we're not
using (when I wrote it back in September and October I thought
we were going to be doing multi-hop garlic routing instead of
tunnels).
I'm also working on seeing if I can get the full blown update
to the tunnel routing to add the per-hop tunnel ids.
As you can see from the roadmap, this encompases a lot of the
0.4.1 release, but since the netDb change meant losing
backwards compatability, we might as well get a slew of
backwards incompatible things done at once.
I'm still running tests in the sim and have to see if I can
finish up the per-hop tunnel id thing, but I hope to have a
new patch release out in a day or two. It won't be backwards
compatible, so it'll be a bumpy upgrade, but it should be
worth it.
* 2) NativeBigInteger
Iakin has been doing some updates to the NativeBigInteger code
for the Freenet team, optimizing some stuff we don't use, but
also putting together some CPU detection code that we can use
to automatically select the right native library. That means
we'll be able to deploy jbigi in a single lib with the default
install and it'll pick the right one without having to ask the
user for anything. He has also agreed to release his mods and
the new CPU detection code so that we can bundle it into our
source (yay Iakin!) I'm not sure when this will be deployed,
but I'll let people know when it is, as those with existing
jbigi libraries will likely need a new one.
* 3) ???
Well, the last week has been a lot of head in the code hacking,
so not too many updates. Anyone have anything else to bring
up? If so, swing on by the meeting tonight, 9p GMT in #i2p.
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQQavYhpxS9rYd+OGEQKiewCg+Bcfv1tTkvMkk6yRnfwKnAKniEgAoN7z
Q36Vr3muI4ti770dlw0mUDLu
=Q3NN
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/07/27/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-07-27
===============================
.. raw:: html
:file: blog/2004/07/27/status.html

142
i2p2www/blog/2004/08/03/status.html Normal file
View File

@@ -0,0 +1,142 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi y'all, lets get this status update out of the way
* Index:
1) 0.3.4 status
2) On deck for 0.3.4.1
3) New web console / I2PTunnel controller
4) 0.4 stuff
5) Other development activities
6) ???
* 1) 0.3.4 status
With last week's 0.3.4 release, the new net is performing pretty
well - irc connections are lasting for several hours at a time and
eepsite retrieval seems to be pretty reliable. Throughput is
still generally low, though slightly improved (I used to see a
consistent 4-5KBps, now I consistently see a 5-8KBps). oOo has
posted up a pair of scripts summarizing the irc activity,
including round trip message time [1] and connection lifetime [2]
(based off hypercubus's bogobot, which was recently committed to
CVS [3])
[1] <a rel="nofollow" href="http://ooo.i2p/roundtrip/">http://ooo.i2p/roundtrip/</a> (the #s are seconds to get a reply)
[2] <a rel="nofollow" href="http://ooo.i2p/roundtrip/connections_reliability.php">http://ooo.i2p/roundtrip/connections_reliability.php</a>
[3] <a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/apps/bogobot/">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/apps/bogobot/</a>
* 2) On deck for 0.3.4.1
As everyone on 0.3.4 has noticed, I was *cough* a little verbose in
my logging, which has been remedied in cvs. In addition, after
writing up some tools [4] to stress the ministreaming lib, I've
added in a 'choke' so that it won't gobble up truckloads of memory
(it will block when trying to add more than 128KB of data into a
stream's buffer, so that when sending a large file, your router
doesn't get that entire file loaded in memory). I think this will
help with the OutOfMemory problems people have been seeing, but I'm
going to add some additional monitoring / debugging code to verify
this.
[4] <a rel="nofollow" href="http://dev.i2p.net/javadoc/net/i2p/client/streaming/">http://dev.i2p.net/javadoc/net/i2p/client/streaming/</a>
StreamSinkServer.html and StreamSinkClient.html
* 3) New web console / I2PTunnel controller
In addition to the above modifications for 0.3.4.1, we've got the
first pass of the new router console ready for some testing. For
a few reasons, we're not going to bundle it as part of the default
install quite yet, so there will be instructions on how to get it
running when the 0.3.4.1 rev comes out in a few days. As you've
seen [5][6], I'm really horrible with web design, and as many of
you have been saying, I should stop farting around with the app
layer and get the core and router rock solid. So, while the new
console has much of the good functionality we want (configure the
router entirely through some simple web pages, offer a quick and
readable summary of the health of the router, expose the ability
to create / edit / stop / start different I2PTunnel instances), I
really need some help from people who are good with the web side
of things.
Technologies used in the new web console are standard JSP [7], CSS,
and simple java beans that query the router / I2PTunnels for data
and process requests. They're all bundled into a pair of .war [8]
files and deployed into an integrated Jetty [9] webserver (which
needs to be started through the router's clientApp.* lines). The
main router console JSPs and beans are pretty technically
solid [10], though the new JSPs and beans I built for managing
I2PTunnel instances are kind of kludgey [11].
[5] <a rel="nofollow" href="http://dev.i2p.net/">http://dev.i2p.net/</a>
[6] fproxy.i2p/SSK@yWJ82tg6D0A-6jg4Ff1GlpM9apUPAgM/jrandom/28//
[7] <a rel="nofollow" href="http://home.duck.i2p/~alexandria/index.php?browse=21&amp;item=392">http://home.duck.i2p/~alexandria/index.php?browse=21&amp;item=392</a>
[8] <a rel="nofollow" href="http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/WebComponents3.html">http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/WebComponents3.html</a>
[9] <a rel="nofollow" href="http://jetty.mortbay.org/jetty/">http://jetty.mortbay.org/jetty/</a>
[10] <a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/apps/routerconsole/">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/apps/routerconsole/</a>
[11] <a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/apps/i2ptunnel/">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/apps/i2ptunnel/</a>
* 4) 0.4 stuff
Beyond the new web interface, the 0.4 release will include
hypercubus' new installer which we haven't really integrated yet.
We also need to do some more large scale simulations (especially
handling of asymmetric applications like IRC and outproxies).
In addition, there are some updates I need to get pushed through to
kaffe/classpath so we can get the new web infrastructure going
on open source JVMs. Plus I've got to put together some more docs
(one on scalability and another analyzing the security/anonymity
under a few common scenarios). We also want to have all of the
improvements you come up with integrated into the new web console.
Oh, and fix whatever bugs you help find :)
* 5) Other development activities
While there has been a lot of progress being made on the base I2P
system, thats only half the story - lots of you are doing some
great work on applications and libraries to make I2P useful. I've
seen some questions in the scrollback regarding who is working on
what, so to help get that info out there, here's everything I know
about (if you're working on something not listed and you want to
share, if I'm mistaken, or if you want to discuss your progress,
please speak up!)
Active development:
= python SAM/I2P lib (devs: sunshine, aum)
= C SAM lib (devs: nightblade)
= python kademlia/I2P DHT (devs: aum)
= v2v - Voice over I2P (devs: aum)
= outproxy load balancing (devs: mule)
Development I've heard about but don't know the status of:
= swarming file transfer / BT (devs: nickster)
Paused development:
= Enclave DHT (devs: nightblade)
= perl SAM lib (devs: BrianR)
= I2PSnark / BT (devs: eco)
= i2pIM (devs: thecrypto)
= httptunnel (devs: mihi)
= MyI2P address book (devs: jrandom)
= MyI2P blogging (devs: jrandom)
* 6) ???
Thats all I can think of for now - swing on by the meeting later
tonight to chat 'bout stuff. As always, 9p GMT on #i2p on the
usual servers.
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQQ/U+BpxS9rYd+OGEQI4+ACgglcWt+LSOPGodCCoqSBsVfl0wxYAoNFO
4z5fWheDRe4o/Tme46jo0ZSm
=zQX7
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/08/03/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-08-03
===============================
.. raw:: html
:file: blog/2004/08/03/status.html

90
i2p2www/blog/2004/08/10/status.html Normal file
View File

@@ -0,0 +1,90 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey everyone, weekly update time
* Index:
1) 0.3.4.1 status
2) Updated docs
3) 0.4 progress
4) ???
* 1) 0.3.4.1 status
Well, we've pushed out the 0.3.4.1 release the other day, and it has
been doing pretty well. Connect times on irc have been consistently
for multiple hours, and transfer rates are doing pretty good as well
(I pulled 25KBps from one eepsite the other day using 3 parallel
streams).
One really cool feature added in with the 0.3.4.1 release (that I
forgot to add to the release announcement) was mule's patch to allow
the eepproxy to round robin non-i2p requests through a series of
outproxies. The default is still just to use the squid.i2p outproxy,
but if you go into your router.config and change the clientApp line
to have:
-e 'httpclient 4444 squid.i2p,www1.squid.i2p'
it will randomly route each HTTP request through one of the two
outproxies listed (squid.i2p and www1.squid.i2p). With that, if
there are a few more people running outproxies, y'all won't be so
dependent upon the squid.i2p. Of course, you've all heard my
concerns regarding outproxies, but having this capability gives
people more options.
We have been seeing some instability over the last few hours, but
with the help of duck and cervantes, I've identified two nasty bugs
and am testing out fixes atm. The fixes are significant, so I do
expect to have a 0.3.4.2 out in the next day or two, after I've
verified the results.
* 2) Updated docs
We've been slacking a bit on getting the documentation on the site
up to date, and while there are still a few big holes (e.g. the
netDb [1] and i2ptunnel [2] docs), we've recently updated a few of
them (network comparisons [3] and the faq [4]). As we are moving
closer to the 0.4 and 1.0 releases, I would appreciate if people
could go through the site and see what can be improved upon.
Of particular note is an updated Hall of Fame [5] - we've finally
got that sync'ed up to reflect the generous donations y'all have
made (thanks!) As we move forward, we will be using these
resources to compensate coders and other contributors, as well as
to offset any costs incurred (e.g. hosting providers, etc).
[1] <a rel="nofollow" href="http://www.i2p.net/how_networkdatabase">http://www.i2p.net/how_networkdatabase</a>
[2] <a rel="nofollow" href="http://www.i2p.net/i2ptunnel">http://www.i2p.net/i2ptunnel</a>
[3] <a rel="nofollow" href="http://www.i2p.net/how_networkcomparisons">http://www.i2p.net/how_networkcomparisons</a>
[4] <a rel="nofollow" href="http://www.i2p.net/faq">http://www.i2p.net/faq</a>
[5] <a rel="nofollow" href="http://www.i2p.net/halloffame">http://www.i2p.net/halloffame</a>
* 3) 0.4 progress
Looking back at last week's notes [6], we've still got a few things
left for 0.4, but the simulations have been going quite well, and
the majority of the kaffe problems have been found. What would be
great though is if people could hammer away at different aspects of
the router or the client apps and file any bugs [7] you come across.
[6] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p/2004-August/000388.html">http://dev.i2p.net/pipermail/i2p/2004-August/000388.html</a>
[7] <a rel="nofollow" href="http://dev.i2p.net/bugzilla/index.cgi">http://dev.i2p.net/bugzilla/index.cgi</a>
* 4) ???
Thats all I've got to bring up at the moment - I appreciate the time
y'all are taking to help move us forward, and I think we're making
great progress. Of course, if anyone has anything else they want
to talk about, swing on by the meeting in #i2p at... er... now :)
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQRk3nRpxS9rYd+OGEQL+awCg7Yr7WymeuXym18VqI8XnDowg/DIAn1/G
E+89jypnECNyg/uF1RHuy1Fy
=a6a5
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/08/10/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-08-10
===============================
.. raw:: html
:file: blog/2004/08/10/status.html

70
i2p2www/blog/2004/08/17/status.html Normal file
View File

@@ -0,0 +1,70 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, update time
* Index:
1) Network status and 0.3.4.3
2) Stasher
3) ???
* 1) Network status and 0.3.4.3
While the network has been functional over the last week, there has
been a lot of trouble at times, leading to a dramatic decrease in
reliability. The 0.3.4.2 release has helped out significantly in
addressing a DoS caused by some incompatability and time
synchronization issues - see the graph of network database
requests [1] showing the DoS (spikes off the chart) which was
stopped by the introduction of 0.3.4.2. Unfortunately, that in
turn introduced its own set of issues, causing a significant number
of messages to be retransmitted, as can be seen in the bandwidth
plot [2]. The increased load there was also due to an actual
increase in user activity, so its not /that/ crazy ;) But still,
it was a problem.
Over the last few days, I've been pretty selfish. We've had a bunch
of bugfixes tested and deployed on a few routers, but I haven't
released it yet, since I rarely get to test out the interplay of
incompatabilities in the software when I run my sims. So, you've
been subjected to exceedingly shitty network operation while I
tweak things to find ways to let routers perform well when a lot
of routers suck. We're making progress on that front - profiling
and avoiding peers who exploit the network database, managing
network database request queues more efficiently, and enforcing
tunnel diversification.
We're not there yet, but I'm hopeful. Tests are being run now on the
live net, and when its ready, there will be a 0.3.4.3 release pushing
the results.
[1] <a rel="nofollow" href="http://dev.i2p.net/~jrandom/netdb.png">http://dev.i2p.net/~jrandom/netdb.png</a>
[2] <a rel="nofollow" href="http://dev.i2p.net/~jrandom/bandwidth.png">http://dev.i2p.net/~jrandom/bandwidth.png</a>
* 2) Stasher
Aum has been doing some kickass work on his DHT [3], and while it
currently has some significant limitations, it looks promising. Its
definitely not ready for general use yet, but if you're up for
helping him out with testing (or coding :), check out the site and
start up a node.
[3] <a rel="nofollow" href="http://stasher.i2p/">http://stasher.i2p/</a>
* 3) ???
Thats 'bout it for now. Since the meeting should have started a
minute ago, I should probably wrap this up. See y'all in #i2p!
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQSJyyxpxS9rYd+OGEQLm1QCgtKDgiaghNWIy73JEWHIyxzhLvBQAn1q8
i0kp7DNZkldsLH2uenA0mpeI
=ZA99
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/08/17/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-08-17
===============================
.. raw:: html
:file: blog/2004/08/17/status.html

215
i2p2www/blog/2004/08/24/status.html Normal file
View File

@@ -0,0 +1,215 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi everyone, lots of updates today
* Index
1) 0.3.4.3 status
1.1) timestamper
1.2) new router console authentication
2) 0.4 status
2.1) service &amp; systray integration
2.2) jbigi &amp; jcpuid
2.3) i2paddresshelper
3) AMOC vs. restricted routes
4) stasher
5) pages of note
6) ???
* 1) 0.3.4.3 status
The 0.3.4.3 release came out last Friday and things have been going
pretty well since. There have been some problems with some newly
introduced tunnel testing and peer selection code, but after some
tweaking since the release, its pretty solid. I don't know if the
irc server is on the new rev yet, so we generally have to rely on
testing with eepsites and the http outproxies (squid.i2p and
www1.squid.i2p). Large (&gt;5MB) file transfers in the 0.3.4.3
release are still not reliable enough, but in my testing, the
modifications since then have improved things further.
The network has been growing as well - we hit 45 concurrent users
earlier today, and have been consistently in the 38-44 user range
for a few days (w00t)! This is a healthy number for the moment, and
I've been monitoring the overall network activity to watch for
dangers. When moving to the 0.4 release, we're going to want to
gradually increase the userbase up to around the 100 router mark and
test some more before growing further. At least, thats my goal from
a developer's perspective.
* 1.1) timestamper
One of the totally kickass things that changed with the 0.3.4.3
release that I completely forgot to mention was an update to the
SNTP code. Thanks to the generosity of Adam Buckley, who has agreed
to release his SNTP code under the BSD license, we have merged the
old Timestamper app into the core I2P SDK and integrated it fully
with our clock. This means three things:
1) you can delete the timestamper.jar (the code is in i2p.jar now)
2) you can remove the related clientApp lines from your config
3) you can update your config to use the new time sync options
The new options in the router.config are simple, and the default
values should be good enough (especially true since the majority of
you are unintentially using them :)
To set the list of SNTP servers to query:
time.sntpServerList=pool.ntp.org,pool.ntp.org,pool.ntp.org
To disable the time synchronization (only if you are an NTP guru and
know that your OS's clock is *always* right - running &quot;windows time&quot;
is NOT sufficient):
time.disabled=true
You don't need to have a 'timestamper password' anymore, since it is
all integrated into the code directly (ah, the joys of BSD vs GPL :)
* 1.2) new router console authentication
This is only relevent for those of you running the new router
console, but if you have it listening on a public interface, you may
want to take advantage of the integrated basic HTTP authentication.
Yes, basic HTTP authentication is absurdly weak - it won't protect
against anyone who sniffs your network or brute forces their way in,
but it'll keep out the casual sneak. Anyway, to use it, simply add
the line
consolePassword=blah
to your router.config. You will, unfortunately, have to restart the
router, as this parameter is fed into Jetty only once (during
startup).
* 2) 0.4 status
We're making a lot of headway on the 0.4 release, and we hope to get
some prerelease versions out there in the next week. We're still
hammering out some details though, so we don't have a solid upgrade
process put together yet. The release will be backwards compatible,
so it shouldn't be too painful of an update. Anyway, keep an ear to
the ground and you'll know when things are ready.
* 2.1) service &amp; systray integration
Hypercubus is making lots of progress on integrating the installer,
a systray application, and some service management code. Basically,
for the 0.4 release all windows users will automatically have a small
systray icon (Iggy!), though they will be able to disable (and/or
reenable) that through the web console. In addition, we're going to
be bundling the JavaService [1] wrapper, which will let us do all
sorts of cool things, such as run I2P on system boot (or not),
auto-restart on some conditions, hard JVM restart on demand,
generate stack traces, and all sorts of other goodies.
[1] <a rel="nofollow" href="http://wrapper.tanukisoftware.org/doc/english/">http://wrapper.tanukisoftware.org/doc/english/</a>
* 2.2) jbigi &amp; jcpuid
One of the big updates in the 0.4 release will be an overhaul of the
jbigi code, merging in the modifications Iakin made for Freenet as
well as Iakin's new &quot;jcpuid&quot; native library. The jcpuid library
works only on x86 architectures and, in tandem with some new jbigi
code, will determine the 'right' jbigi to load. As such, we will
be shipping a single jbigi.jar that everyone will have, and from it
select the 'right' one for the current machine. People will of
course still be able to build their own native jbigi, overriding
what jcpuid wants (simply build it and copy it into your I2P
installation directory, or name it &quot;jbigi&quot; and place it in a .jar
file in your classpath). However, because of the updates, it is
*not* backwards compatible - when upgrading, you must either
rebuild your own jbigi or remove your existing native library (to
let the new jcpuid code choose the right one).
* 2.3) i2paddresshelper
oOo has put together a really cool helper to let people browse
eepsites without updating their hosts.txt. It is committed to CVS
and will be deployed in the next release, but people may want to
consider updating links accordingly (cervantes has updated
forum.i2p's [i2p] bbcode to support it with a &quot;Try it [i2p]&quot; link).
Basically you just make a link to the eepsite with whatever name you
want, then tack on a special url parameter specifying the
destination:
<a rel="nofollow" href="http://wowthisiscool.i2p/?i2paddresshelper=FpCkYW5pw">http://wowthisiscool.i2p/?i2paddresshelper=FpCkYW5pw</a>...
Behind the scenes, its pretty safe - you can't spoof some other
address, and the name is *not* persisted in hosts.txt, but it will
let you see images / etc linked to on eepsites that you wouldn't be
able to with the old <a rel="nofollow" href="http://i2p/base64/">http://i2p/base64/</a> trick. If you want to always
be able to use &quot;wowthisiscool.i2p&quot; to reach that site, you will
still of course have to add the entry to your hosts.txt (until the
MyI2P address book is pushed out, that is ;)
* 3) AMOC vs. restricted routes
Mule has been throwing together some ideas and prodding me to explain
some things, and in the process, he has been making some headway in
getting me to reevaluate the whole AMOC idea. Specifically, if we
drop one of the constraints I've placed on our transport layer -
allowing us to assume bidirectionality - we may be able to scrap
the whole AMOC transport, instead implementing some basic restricted
route operation (leaving the foundations for more advanced
restricted route techniques, like trusted peers and multihop router
tunnels for later).
If we go this route, it would mean people would be able to
participate in the network behind firewalls, NATs, etc with no
configuration, as well as offer some of the restricted route
anonymity properties. In turn, it would likely cause a big revamp
to our roadmap [2], but if we can do it safely, it would save us a
truckload of time and be well worth the change.
However, we don't want to rush it, and will need to review the
anonymity and security implications carefully before committing to
that path. We'll do so after 0.4 is out and going smoothly, so
there is no rush.
[2] <a rel="nofollow" href="http://www.i2p.net/roadmap">http://www.i2p.net/roadmap</a>
* 4) stasher
Word on the street is that aum is making some good progress - I don't
know if he'll be around for the meeting with an update, but he did
leave us a snippet on #i2p this morning:
&lt;aum&gt; hi all, can't talk long, just a quick stasher update - work is
continuing on implementing freenet keytypes, and freenet FCP
compatibility - work in progress, should have a test build
ready to try out by the end of the week
w00t.
* 5) pages of note
I just want to point out two new resources available that I2P users
may want to check out - DrWoo has put together a page [3] with a
whole bunch of info for people who want to browse anonymously, and
Luckypunk has posted up a howto describing his experiences with some
JVMs on FreeBSD [4]. Hypercubus also posted the docs [5] on testing
out the not-yet-released service &amp; systray integration.
[3] <a rel="nofollow" href="http://brittanyworld.i2p/browsing">http://brittanyworld.i2p/browsing</a>
[4] <a rel="nofollow" href="http://forum.i2p.net/viewtopic.php?t=54">http://forum.i2p.net/viewtopic.php?t=54</a>
[5] <a rel="nofollow" href="http://forum.i2p.net/viewtopic.php?t=55">http://forum.i2p.net/viewtopic.php?t=55</a>
* 6) ???
Ok, thats all I've got to say at the moment - swing by the meeting
tonight at 9p GMT if you'd like to bring something else up.
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQSt/VhpxS9rYd+OGEQKZlwCgrsl5J6PhELxy2cGEairz+zPU80sAoIjW
JDLmPE9nXRLzrRWdTTRJ1JHH
=hNz9
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/08/24/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-08-24
===============================
.. raw:: html
:file: blog/2004/08/24/status.html

161
i2p2www/blog/2004/08/31/status.html Normal file
View File

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

6
i2p2www/blog/2004/08/31/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-08-31
===============================
.. raw:: html
:file: blog/2004/08/31/status.html

129
i2p2www/blog/2004/09/08/status.html Normal file
View File

@@ -0,0 +1,129 @@
<pre>-----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] <a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD</a>
* 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 &quot;too many&quot; 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 &quot;kindness factor&quot;, 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 <a rel="nofollow" href="http://localhost:7657/">http://localhost:7657/</a> 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,
&quot;hmm. we should probably have some help text here.&quot;
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 <a rel="nofollow" href="http://localhost:7657/i2ptunnel/">http://localhost:7657/i2ptunnel/</a> interface &quot;spartan&quot;
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 &quot;big problems&quot;, 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] <a rel="nofollow" href="http://www.i2p.net/roadmap">http://www.i2p.net/roadmap</a>
[3] <a rel="nofollow" href="http://www.i2p.net/todo">http://www.i2p.net/todo</a>
[4] <a rel="nofollow" href="http://www.i2p.net/todo#connection">http://www.i2p.net/todo#connection</a>
* 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-----
</pre>

6
i2p2www/blog/2004/09/08/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-09-08
===============================
.. raw:: html
:file: blog/2004/09/08/status.html

197
i2p2www/blog/2004/09/14/status.html Normal file
View File

@@ -0,0 +1,197 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, its that time of the week again
* Index:
1) 0.4.0.1
2) Threat model updates
3) Website updates
4) Roadmap
5) Client apps
6) ???
* 1) 0.4.0.1
Since last Wednesday's 0.4.0.1 release, things have been going
pretty well on the net - more than 2/3rd of the network has
upgraded, and we'e been maintaining between 60 and 80 routers on
the network. IRC connection times vary, but lately 4-12 hour
connections have been normal. There have been some reports of
funkiness starting up on OS/X though, but I believe some
progress is being made on that front too.
* 2) Threat model updates
As mentioned in reply [1] to Toni's post [2], there has been a
pretty substantial rewrite of the threat model [3]. The main
difference is that rather than the old way of addressing the
threats in an ad-hoc manner, I tried to follow some of the
taxonomies offered within the literature [4]. The biggest
problem for me was finding ways to fit the actual techniques
people can use into the patterns offered - often a single
attack fit within several different categories. As such, I'm
not really too pleased with how the information in that page
is conveyed, but its better than it was before.
[1] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p/2004-September/000442.html">http://dev.i2p.net/pipermail/i2p/2004-September/000442.html</a>
[2] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p/2004-September/000441.html">http://dev.i2p.net/pipermail/i2p/2004-September/000441.html</a>
[3] <a rel="nofollow" href="http://www.i2p.net/how_threatmodel">http://www.i2p.net/how_threatmodel</a>
[4] <a rel="nofollow" href="http://freehaven.net/anonbib/topic.html">http://freehaven.net/anonbib/topic.html</a>
* 3) Website updates
Thanks to Curiosity's help, we've begun on some updates to the
website - the most visible of which you can see on the homepage
itself. This should help people out who stumble upon I2P and
want to know right off the bat wtf this I2P thing is, rather
than having to hunt and peck through the various pages. In any
case, progress, ever onwards :)
* 4) Roadmap
Speaking of progress, I've finally thrown together a revamped
roadmap [5] based upon what I feel we need to implement and upon
what must be accomplished to provide for the user's needs. The
major changes to the old roadmap are:
* Drop AMOC altogether, replaced with UDP (however, we'll support
TCP for those who can't use UDP *cough*mihi*cough*)
* Kept all of the restricted route operation to the 2.0 release,
rather than bring in partial restricted routes earlier. I
believe we'll be able to meet the needs of many users without
restricted routes, though of course with them many more users
will be able to join us. Walk before run, as they say.
* Pulled the streaming lib in to the 0.4.3 release, as we don't
want to go 1.0 with the ~4KBps per stream limit. The bounty on
this is still of course valid, but if no one claims it before
0.4.2 is done, I'll start working on it.
* TCP revamp moved to 0.4.1 to address some of our uglier issues
(high CPU usage when connecting to people, the whole mess with
&quot;target changed identities&quot;, adding autodetection of IP address)
The other items scheduled for various 0.4.* releases have already
been implemented. However, there is one other thing dropped from
the roadmap...
[5] <a rel="nofollow" href="http://www.i2p.net/roadmap">http://www.i2p.net/roadmap</a>
* 5) Client apps
We need client applications. Applications that are engaging,
secure, scalable, and anonymous. I2P by itself doesn't do much,
it merely lets two endpoints talk to each other anonymously.
While I2PTunnel does offer one hell of a swiss army knife, tools
like that are only really engaging to the geeks among us. We need
more than that - we need something that lets people do what they
actually want to do, and that helps them do it better. We need a
reason for people to use I2P beyond simply because its safer.
So far I've been touting MyI2P to meet that need - a distributed
blogging system offering a LiveJournal-esque interface. I
recently [6] discussed some of the functionality within MyI2P on
the list. However, I've pulled it out of the roadmap as its just
too much work for me to do and still give the base I2P network the
attention it needs (we're already packed extremely tight [7]).
There are a few other apps that have much promise. Stasher [8]
would provide a significant infrastructure for distributed data
storage, but I'm not sure how that's progressing. Even with
Stasher, however, there would need to be an engaging user
interface (though some FCP apps may be able to work with it).
IRC is also a potent system, though has its limitations due to
the server-based architecture. oOo has done some work to see
about implementing transparent DCC though, so perhaps the IRC
side could be used for public chat and DCC for private file
transfers or serverless chat.
General eepsite functionality is also important, and what we
have now is completely unsatisfactory. As DrWoo points out [9],
there are significant anonymity risks with the current setup,
and even though oOo has made some patches filtering some
headers, there is much more work to be done before eepsites can
be considered secure. There are a few different approaches to
addressing this, all of which can work, but all of which
require work. I do know that duck mentioned he had someone
working on something, though I don't know how thats coming or
whether it could be bundled in with I2P for everyone to use
or not. Duck?
Another pair of client apps that could help would be either a
swarming file transfer app (ala BitTorrent) or a more
traditional file sharing app (ala DC/Napster/Gnutella/etc).
This is what I suspect a large number of people want, but there
are issues with each of these systems. However, they're well
known and porting may not be much trouble (perhaps).
Ok, so the above isn't anything new - why did I bring them all
up? Well, we need to find a way to get an engaging, secure,
scalable, and anonymous client application implemented, and it
isn't going to happen all by itself out of the blue. I've come
to accept that I'm not going to be able to do it myself, so we
need to be proactive and find a way to get it done.
To do so, I think our bounty system may be able to help, but I
think one of the reasons we haven't seen much activity on that
front (people working on implementing a bounty) is because
they're spread too thin. To get the results we need, I feel we
need to prioritize what we want and focus our efforts on that
top item, 'sweetening the pot' so as to hopefully encourage
someone to step up and work on the bounty.
My personal opinion is still that a secure and distributed
blogging system like MyI2P would be best. Rather than simply
shoveling data back and forth anonymously, it offers a way to
build communities, the lifeblood of any development effort. In
addition, it offers a relatively high signal to noise ratio,
low chance for abuse of the commons, and in general, a light
network load. It doesn't, however, offer the full richness of
normal websites, but the 1.8 million active LiveJournal users
don't seem to mind.
Beyond that, securing the eepsite architecture would be my
next preference, allowing browsers the safety they need and
letting people serve eepsites 'out of the box'.
File transfer and distributed data storage are also incredibly
powerful, but they don't seem to be as community oriented as
we probably want for the first normal end user app.
I want all of the apps listed to be implemented yesterday, as
well as a thousand other apps I couldn't begin to dream of. I
also want world peace, and end to hunger, the destruction of
capitalism, freedom from statism, racism, sexism, homophibia,
an end to the outright destruction of the environment and all
that other evil stuff. However, we are only so many people
and we can only accomplish so much. As such, we must
prioritize and focus our efforts on achieving what we can
rather than sit around overwhelmed with all we want to do.
Perhaps we can discuss some ideas about what we should do in
the meeting tonight.
[6] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p/2004-September/000435.html">http://dev.i2p.net/pipermail/i2p/2004-September/000435.html</a>
[7] <a rel="nofollow" href="http://www.i2p.net/images/plan.png">http://www.i2p.net/images/plan.png</a>
[8] <a rel="nofollow" href="http://www.freenet.org.nz/python/stasher/">http://www.freenet.org.nz/python/stasher/</a>
[9] <a rel="nofollow" href="http://brittanyworld.i2p/browsing/">http://brittanyworld.i2p/browsing/</a>
* 6) ???
Well, thats all I've got for the moment, and hey, I got the
status notes written up *before* the meeting! So no excuses,
swing on by at 9pm GMT and barrage us all with your ideas.
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQUc1OhpxS9rYd+OGEQLaYQCg0qql8muvuGEh46VICx4t69PuRl8An0Ki
3GEF2jrg/i9csiMO6VdQccxH
=4Tip
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/09/14/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-09-14
===============================
.. raw:: html
:file: blog/2004/09/14/status.html

55
i2p2www/blog/2004/09/21/status.html Normal file
View File

@@ -0,0 +1,55 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi gang, quick update this week
* Index
1) Dev status
2) New userhosts.txt vs. hosts.txt
3) ???
* 1) Dev status
The network has been fairly stable over the last week, so
I've been able to focus my time on the 0.4.1 release -
revamping the TCP transport and adding support for detecting
IP addresses and removing that old &quot;target changed identities&quot;
thing. This should also get rid of the need for dyndns
entries as well.
It won't be the ideal 0-click setup for people behind NATs
or firewalls - they'll still need to do the port forwarding
so they can receive inbound TCP connections. It should
however be less error prone. I'm doing my best to keep it
backwards compatible, but I'm not making any promises on that
front. More news when its ready.
* 2) New userhosts.txt vs. hosts.txt
In the next release we'll have the oft-requested support for
a pair of hosts.txt files - one that is overwritten during
upgrades (or from <a rel="nofollow" href="http://dev.i2p.net/i2p/hosts.txt">http://dev.i2p.net/i2p/hosts.txt</a>) and one
that the user can maintain locally. In the next release (or
CVS HEAD) you can edit the file &quot;userhosts.txt&quot; which is
checked before hosts.txt for any entries - please make your
local changes there, since the update process will overwrite
hosts.txt (but not userhosts.txt).
* 3) ???
As I mentioned, only a brief set of notes this week. Anyone
have anything else they want to bring up? Swing on by the
meeting in a few minutes.
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQVCVAxpxS9rYd+OGEQIdswCg1gpn/wMwppYT4DnNss+ChBi+U7MAnAuW
6hqOqejKAcOQD1WwBQ8nhFdg
=oiU1
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/09/21/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-09-21
===============================
.. raw:: html
:file: blog/2004/09/21/status.html

87
i2p2www/blog/2004/09/28/status.html Normal file
View File

@@ -0,0 +1,87 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, weekly update time
* Index:
1) New transport
2) 0.4.1 status
3) ???
* 1) New transport
The 0.4.1 release has been taking longer than expected, but the new
transport protocol and implementation is in place with everything
that has been planned - IP detection, low cost connection
establishment, and an easier interface to help debug when
connections are failing. This is done by completely throwing out
the old transport protocol and implementing a new one, though we've
still got the same buzzwords (2048bit DH + STS, AES256/CBC/PKCS#5).
If you'd like to review the protocol, its in the docs [1]. The new
implementation is also a lot cleaner, since the old version was just
a bunch of updates accumulated over the last year.
[1]
<a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/java/src/net/i2p/rout">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/java/src/net/i2p/rout</a>
er/transport/tcp/package.html?&amp;content-type=text/html
Anyway, there are some things in the new IP detection code that are
worth mentioning. Most importantly, it is entirely optional - if
you specify an IP address on the config page (or in the
router.config itself), it will always use that address, no matter
what. However, if you leave that blank, your router will let the
first peer it contacts tell it what its IP address is, which it will
then start listening on (after adding that to its own RouterInfo and
placing that in the network database). Well, thats not quite true -
if you haven't explicitly set an IP address, it will trust anyone to
tell it what IP address it can be reached at whenever the peer has
no connections. So, if your internet connection restarts, perhaps
giving you a new DHCP address, your router will trust the first peer
it is able to reach.
Yes, this means no more dyndns. You're still of course welcome to
keep using it, but its not necessary.
However, this does not do all that you want - if you have a NAT or
firewall, knowing your external IP address is only half of the
battle - you still need to poke the hole for the inbound port. But,
its a start.
(as an aside, for people running their own private I2P networks or
simulators, there is a new pair of flags to be set
i2np.tcp.allowLocal and i2np.tcp.tagFile)
* 2) 0.4.1 status
Beyond the items on the roadmap for 0.4.1, I want to get a few more
things in there - both bugfixes and network monitoring updates. I'm
tracking down some excessive memory churn issues at the moment, and
I want to explore some hypotheses about the occational reliability
issues on the net, but we'll be ready to roll out the release soon,
perhaps thursday. It unfortunately will not be backwards compatible,
so it'll be a little bumpy, but with the new upgrade process and the
more forgiving transport implementation, it shouldn't be as bad as
the previous backwards incompatible updates.
* 3) ???
Yeah, we've had short updates the last two weeks, but thats because
we're in the trenches focusing on the implementation, rather than
various higher level designs. I could tell you about the profiling
data, or the 10,000 connection tag cache for the new transport, but
thats not so interesting. However y'all may have some additional
things to discuss, so swing on by the meeting tonight and let 'er
rip.
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQVmbSxpxS9rYd+OGEQLRLQCfXYW9hGbiTALFtsv7L803qAJlFocAoPPO
+PlRUSxbgmI4M7QSDte/eCnP
=vO07
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/09/28/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-09-28
===============================
.. raw:: html
:file: blog/2004/09/28/status.html

167
i2p2www/blog/2004/10/05/status.html Normal file
View File

@@ -0,0 +1,167 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, its weekly update time
* Index:
1) 0.4.1.1 status
2) Pretty pictures
3) 0.4.1.2 and 0.4.2
4) Bundled eepserver
5) ???
* 1) 0.4.1.1 status
After a pretty bumpy 0.4.1 release (and subsequent rapid 0.4.1.1
update), the net seems to be back to normal - 50-something peers
actrive at the moment, and both irc and eepsites are reachable. Most
of the pain was caused by insufficient testing of the new transport
outside lab conditions (e.g. sockets breaking at strange times,
excessive delays, etc). Next time we need to make changes at that
layer, we'll be sure to test it more widely prior to release.
* 2) Pretty pictures
Over the last few days there have been a large number of updates
going on in CVS, and one of the new things added was a new stat
logging component, allowing us to simply pull out the raw stat data
as its being generated, rather than deal with the crude averages
gathered on /stats.jsp. With it, I've been monitoring a few key
stats on a few routers, and we're getting closer to tracking down the
remaining stability issues. The raw stats are fairly bulky (a
20-hour run on duck's box generated almost 60MB of data), but thats
why we've got pretty pictures - <a rel="nofollow" href="http://dev.i2p.net/~jrandom/stats/">http://dev.i2p.net/~jrandom/stats/</a>
The Y axis on most of those is milliseconds, while the X axis is
seconds. There are a few interesting things to note. First,
client.sendAckTime.png is a pretty good approximation of a single
round trip delay, as the ack message is sent with the payload and
then returns the full path of the tunnel - as such, the vast majority
of the nearly 33,000 successful messages sent had a round trip time
under 10 seconds. If we then review the client.sendsPerFailure.png
along side client.sendAttemptAverage.png, we see that the 563 failed
sends were almost all sent the maximum number of retries we allow (5
with a 10s soft timeout per try and 60s hard timeout) while most of
the other attempts succeeded on the first or second try.
Another interesting image is client.timeout.png which sheds much
doubt on a hypothesis I had - that the message send failures were
correlated with some sort of local congestion. The plotted data
shows that the inbound bandwidth usage varied widely when failures
occurred, there were no consistent spikes in local send processing
time, and seemingly no pattern whatsoever with tunnel test latency.
The files dbResponseTime.png and dbResponseTime2.png are similar to
the client.sendAckTime.png, except they correspond to netDb messages
instead of end to end client messages.
The transport.sendMessageFailedLifetime.png shows how long we sit on
a message locally before failing it for some reason (for instance,
due to its expiration being reached or the peer it is targetting
being unreachable). Some failures are unavoidable, but this image
shows a significant number failing right after the local send timeout
(10s). There are a few things we can do to address this:
- first, we can make the shitlist more adaptive- exponentially
increasing the period a peer is shitlisted for, rather than a flat 4
minutes each. (this has already been committed to CVS)
- second, we can preemptively fail messages when it looks like
they'd fail anyway. To do this, we have each connection keep track
of its send rate and whenever a new message is added to its queue, if
the number of bytes already queued up divided by the send rate
exceeds the time left until expiration, fail the message immediately.
We may also be able to use this metric when determining whether to
accept any more tunnel requests through a peer.
Anyway, on to the next pretty picture -
transport.sendProcessingTime.png. In this you see that this
particular machine is rarely responsible for much lag - typically
10-100ms, though some spikes to 1s or more.
Each point plotted in the tunnel.participatingMessagesProcessed.png
represents how many messages were passed along a tunnel that router
participated in. Combining this with the average message size gives
us an estimated network load that the peer takes on for other people.
The last image is the tunnel.testSuccessTime.png, showing how long it
takes to send a message out a tunnel and back home again through
another inbound tunnel, giving us an estimage of how good our tunnels
are.
Ok, thats enough pretty pictures for now. You can generate the data
yourself with any release after 0.4.1.1-6 by setting the router
config property &quot;stat.logFilters&quot; to a comma seperated list of stat
names (grab the names from the /stats.jsp page). That is dumped to
stats.log which you can process with
java -cp lib/i2p.jar net.i2p.stat.StatLogFilter stat.log
which splits it up into seperate files for each stat, suitable for
loading into your favorite tool (e.g. gnuplot).
3) 0.4.1.2 and 0.4.2
There have been lots of updates since the 0.4.1.1 release (see the
history [1] for a full list), but no critical fixes yet. We'll be
rolling them out in the next 0.4.1.2 patch release later this week
after some outstanding bugs relating to IP autodetection are
addressed.
The next major task at that point will be to hit 0.4.2, which is
currently slated [2] as a major revamp to the tunnel processing. Its
going to be a lot of work, revising the encryption and message
processing as well as the tunnel pooling, but its pretty critical, as
an attacker could fairly easily mount some statistical attacks on the
tunnels right now (e.g. predecessor w/ random tunnel ordering or
netDb harvesting).
dm raised the question however as to whether it'd make sense to do
the streaming lib first (currently planned for the 0.4.3 release).
The benefit of that would be the network would become both more
reliable and have better throughput, encouraging other developers to
get hacking on client apps. After that's in place, I could then
return to the tunnel revamp and address the (non-user-visible)
security issues.
Technically, the two tasks planned for 0.4.2 and 0.4.3 are
orthogonal, and they're both going to get done anyway, so there
doesn't seem to be much of a downside to switching those around. I'm
inclined to agree with dm, and unless someone can come up with some
reasons to keep 0.4.2 as the tunnel update and 0.4.3 as the streaming
lib, we'll switch 'em.
[1] <a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD</a>
[2] <a rel="nofollow" href="http://www.i2p.net/roadmap">http://www.i2p.net/roadmap</a>
* 4) Bundled eepserver
As was mentioned in the 0.4.1 release notes [3], we've bunded the
software and configuration necessary for running an eepsite out of
the box - you can simply drop a file in the ./eepsite/docroot/
directory and share the I2P destination found on the router console.
A few people called me on my zeal for .war files though - most apps
unfortunately need a little more work than simply dropping a file in
the ./eepsite/webapps/ dir. I've put together a brief tutorial [4]
on running the blojsom [5] blogging engine, and you can see what that
looks like on detonate's site [6].
[3] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p/2004-September/000456.html">http://dev.i2p.net/pipermail/i2p/2004-September/000456.html</a>
[4] <a rel="nofollow" href="http://www.i2p.net/howto_blojsom">http://www.i2p.net/howto_blojsom</a>
[5] <a rel="nofollow" href="http://wiki.blojsom.com/wiki/display/blojsom/About+blojsom">http://wiki.blojsom.com/wiki/display/blojsom/About+blojsom</a>
[6] <a rel="nofollow" href="http://detonate.i2p/">http://detonate.i2p/</a>
* 5) ???
Thats about all I've got at the moment - swing on by the meeting in
90 minutes if you want to discuss things.
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQWL3MxpxS9rYd+OGEQLk1gCfeMpSoYfbIlPWobks3i7lr8MjwDkAoOMS
vkNuIUa6ZwkKMVJWhoZdWto4
=hCGS
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/10/05/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-10-05
===============================
.. raw:: html
:file: blog/2004/10/05/status.html

111
i2p2www/blog/2004/10/12/status.html Normal file
View File

@@ -0,0 +1,111 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi gang, time for our weekly update
* Index:
1) 0.4.1.2
2) 0.4.1.3
3) 0.4.2
4) mail discussions
5) ???
* 1) 0.4.1.2
The new 0.4.1.2 release has been out for a few days and things have
been going pretty much as expected - there have been a few bumps with
the new watchdog component though, causing it to kill your router
when things are Bad rather than to restart it. As I mentioned
earlier today [1], I'm looking for people to use the new stats
logging tool to send me some data, so your help there would be
greatly appreciated.
[1] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p/2004-October/000465.html">http://dev.i2p.net/pipermail/i2p/2004-October/000465.html</a>
* 2) 0.4.1.3
There will be another release before 0.4.2 is out, as I want the
network to be as solid as possible before moving on. What I'm
experimenting with at the moment is a dynamic throttle on the tunnel
pariticpation - telling routers to probabalistically reject requests
if they're flooded or their tunnels are slower than usual. These
probabilities and thresholds are calculated dynamically from the
stats being kept - if your 10 minute tunnel test time is greater than
your 60 minute tunnel test time, accept the tunnel request with a
probability of 60minRate/10minRate (and if your current # of tunnels
is greater than your 60 minute average number of tunnels, accept it
w/ p=60mRate/curTunnels).
Another potential throttle is to smooth the bandwidth along those
lines - rejecting tunnels probabalistically when our bandwidth usage
spikes. Anyway, the intent of all of this is to help spread out the
network usage and balance the tunnels across more people. The main
problem we've had with the load balancing has been an overwhelming
*excess* of capacity, and as such none of our &quot;damn we're slow, lets
reject&quot; triggers have been hit. These new probabalistic ones should
hopefully keep rapid change in check.
I don't have any specific plan for when the 0.4.1.3 release will be
out - maybe the weekend. The data people send in (from above) should
help determine whether this will be worthwhile, or if there are other
avenues more worthwhile.
* 3) 0.4.2
As we discussed in last week's meeting, we've switched around the
0.4.2 and 0.4.3 releases - 0.4.2 will be the new streaming lib, and
0.4.3 will be the tunnel update.
I've been rereviewing the literature for TCP's streaming
functionality and there are some interesting topics of concern for
I2P. Specifically, our high round trip time leans towards something
like XCP [2], and we should probably be quite aggressive with various
forms of explicit congestion notification, though we can't take
advantage of something like the timestamp option, since our clocks
can be skewed by up to a minute.
In addition, we'll want to make sure we can optimize the streaming
lib to handle short lived connections (which vanilla TCP pretty much
sucks at) - for instance, I want to be able to be able to send small
(&lt;32KB) HTTP GET requests and small (&lt;32KB) replies in literally
three messages:
Alice--&gt;Bob: syn+data+close
Bob--&gt;Alice: ack+data+close (the browser gets the response now)
Alice--&gt;Bob: ack (so he doesn't resend the payload)
Anyway, not much code has been cut on this yet, with the protocol
side of things looking pretty much TCP-like and the packets somewhat
like a merging of human's proposal [3] and the old proposal [4]. If
anyone has any suggestions or ideas, or wants to help out with the
implementation, please get in touch.
[2] <a rel="nofollow" href="http://www.ana.lcs.mit.edu/dina/XCP/">http://www.ana.lcs.mit.edu/dina/XCP/</a>
[3] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p/2004-August/000418.html">http://dev.i2p.net/pipermail/i2p/2004-August/000418.html</a>
[4] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p/2004-August/000421.html">http://dev.i2p.net/pipermail/i2p/2004-August/000421.html</a>
* 4) mail discussion
There have been some interesting discussions regarding email in (and
out of) I2P - postman has put a set of ideas online [5] and is
looking for suggestions. There have also been related discussions on
the #mail.i2p. Perhaps we can get postman to give us an update?
[5] <a rel="nofollow" href="http://www.postman.i2p/ideas.html">http://www.postman.i2p/ideas.html</a>
* 5) ???
Thats about it for the moment. Swing on by the meeting in a few
minutes and bring your comments :)
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQWxFBBpxS9rYd+OGEQIdkACgg1DeDOblafN3X5/HqRJ3dSu64ZEAoM6i
uGWqH5WOe6ZCObkRlxVsMj+B
=o5TR
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/10/12/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-10-12
===============================
.. raw:: html
:file: blog/2004/10/12/status.html

95
i2p2www/blog/2004/10/19/status.html Normal file
View File

@@ -0,0 +1,95 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, its tuesday again
* Index
1) 0.4.1.3
2) Tunnel test time, and send processing time
3) Streaming lib
4) files.i2p
5) ???
* 1) 0.4.1.3
The 0.4.1.3 release came out a day or two ago and it looks like most
people have upgraded (thanks!). The net is working fairly well, but
still no revolutionary increase in reliability. However, the
watchdog bugs from 0.4.1.2 have gone away (or at least no one has
mentioned them). My aim is for this 0.4.1.3 release to be the last
patch before 0.4.2, though of course if something big comes up
needing fixing, we'll have another one.
* 2) Tunnel test time, and send processing time
The most significant changes in the 0.4.1.3 release were to the
tunnel testing - rather than having a fixed (30 second!) test period,
we have much more aggressive timeouts that are derived from measured
performance. This is good, as we now mark tunnels as failing when
they are too slow to do anything useful. However, this is bad, as
sometimes tunnels get backed up temporarily, and if we test them
during that period we fail a tunnel that would otherwise work.
A recent plot of how long a tunnel test takes on one router:
<a rel="nofollow" href="http://dev.i2p.net/~jrandom/10sTestTime.png">http://dev.i2p.net/~jrandom/10sTestTime.png</a>
Those are generally ok tunnel test times - they pass through 4 remote
peers (with 2 hop tunnels), giving the bulk of them ~1-200ms per hop.
However, thats not always the case, as you can see - sometimes it
takes on the order of seconds per hop.
Thats where this next plot comes in - the queue time from when one
particular router wanted to send a message to when that message was
flushed out a socket:
<a rel="nofollow" href="http://dev.i2p.net/~jrandom/processingTime.png">http://dev.i2p.net/~jrandom/processingTime.png</a>
The top 95% or so are under 50ms, but the spikes are killer.
We need to get rid of those spikes, as well as work around situations
with more failing peers. As it stands now, when we 'learn' about a
peer failing our tunnels, we aren't really learning anything
particular to their router - those spikes can cause even high
capacity peers to seem slow if we hit it right.
* 3) Streaming lib
The second part of getting around failing tunnels will be
accomplished in part by the streaming lib - giving us much more
robust end to end streaming communication. This discussion is
nothing new - the lib will do all the whizbang stuff we've been
talking about for a while (and it'll have its share of bugs, of
course). There has been a lot of progress on this front, and the
implementation is probably 60% there.
More news when there's more news.
* 4) files.i2p
Ok, we've had a lot of new eepsites lately, which is kickass. I just
want to point out this one especially as its got a pretty neat
feature for the rest of us. If you haven't been to files.i2p, its
basically a google-like search engine, with a cache of the sites it
spiders (so you can both search and browse when the eepsite is
offline). v.cool.
* 5) ???
This week's status notes are pretty brief, but there's lots going on
- - I just don't have time to write more before the meeting. So, swing
on by #i2p in a few minutes and we can discuss whatever I foolishly
overlooked.
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQXWACRpxS9rYd+OGEQL4NwCfQ6NiuQWmuKyFZCNSuvnhjPlW/GgAoPYI
azbFco6lKpQW9SM631nLXXZB
=ki2I
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/10/19/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-10-19
===============================
.. raw:: html
:file: blog/2004/10/19/status.html

91
i2p2www/blog/2004/10/26/status.html Normal file
View File

@@ -0,0 +1,91 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, weekly update time
* Index
1) Net status
2) Streaming lib
3) mail.i2p progress
4) ???
* 1) Net status
I don't want to jinx it, but for the last week the network has been
pretty much as before - fairly stable for irc, eepsites loading
reliably, though large files still often require resuming. Basically
nothing new to report, beyond the fact that there's
nothing new to report.
Oh, one thing we found was that while Jetty supports HTTP resume, it
only does so for HTTP 1.1. Thats fine for most browsers and
download tools, *except* wget - wget sends the resume request as HTTP
1.0. So, for downloading large files, use curl or some other HTTP
1.1 resume-capable tool (thanks to duck and ardvark for digging in
and finding a solution!)
* 2) Streaming lib
Since the network has been fairly stable, nearly all of my time has
been spent working on the new streaming lib. While its not done yet,
there has been a lot of progress - the basic scenarios all work fine,
the sliding windows are doing well for self-clocking, and the new lib
works as a drop-in replacement for the old one, from the client's
perspective (the two streaming libs can't talk to each other though).
The last few days I've been working through some more interesting
scenarios. The most important one is the laggy network, which we
simulate by injecting delays on messages received - either a simple
0-30s random delay or a tiered delay (80% of the time have a 0-10s
lag, 10% @ 10-20s lag, 5% @ 20-30s, 3% @ 30-40s, 4% @ 40-50s).
Another important test has been the random dropping of messages -
this shouldn't be common on I2P, but we should be able to deal with
it.
The overall performance has been pretty good, but there is still a
lot of work to do before we can deploy this on the live net. This
update will be 'dangerous' in that it is tremendously powerful - if
done horribly wrong, we can DDoS ourselves in a heartbeat, but if
done right, well, let me just say there's a lot of potential
(underpromise and overdeliver).
So, that said, and since the network is fairly 'steady state', I'm in
no rush to push out something not sufficiently tested. More news
when there's more news.
* 3) mail.i2p progress
postman &amp; gang have been working hard for mail over i2p (see
www.postman.i2p), and there is some exciting stuff coming down the
line - perhaps postman has an update for us?
As an aside, I do understand and relate to the calls for a webmail
interface, but postman is swamped doing some neat stuff on the
back end of the mail system. An alternative however is to install a
webmail interface *locally* in your own webserver - there are webmail
JSP/servlet things out there. That would let you run your own local
webmail interface at e.g. <a rel="nofollow" href="http://localhost:7657/mail/">http://localhost:7657/mail/</a>
I know there are some open source scripts out there for accessing
pop3 accounts, which gets us halfway there - perhaps someone could
look around for some that supports pop3 and authenticated SMTP?
c'mon, you know you want to!
* 4) ???
Ok, thats all I've got to say atm - swing on by the meeting in a few
minutes and let us know whats going on.
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQX66GBpxS9rYd+OGEQJBmQCdEmOFuBtd0muoaqwibMvdO+P0bLQAoNNT
zFtdHN6Y54VUcfsFl6+5W/3B
=195H
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/10/26/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-10-26
===============================
.. raw:: html
:file: blog/2004/10/26/status.html

92
i2p2www/blog/2004/11/02/status.html Normal file
View File

@@ -0,0 +1,92 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, time for the weekly update
* Index:
1) Net status
2) Core updates
3) Streaming lib
4) mail.i2p progress
5) BT progress
6) ???
* 1) Net status
Pretty much as before - a steady number of peers, eepsites fairly
reachable, and irc for hours on end. You can get a peek at the
reachability of various eepsites through a few different pages:
- <a rel="nofollow" href="http://gott.i2p/sites.html">http://gott.i2p/sites.html</a>
- <a rel="nofollow" href="http://www.baffled.i2p/links.html">http://www.baffled.i2p/links.html</a>
- <a rel="nofollow" href="http://thetower.i2p/pings.txt">http://thetower.i2p/pings.txt</a>
* 2) Core updates
For those hanging out in the channel (or reading the CVS logs),
you've seen a lot of things going on, even though its been a while
since the last release. A full list of changes since the 0.4.1.3
release can be found online [1], but there are two major
modifications, one good and one bad:
The good one is that we've dramatically cut down on the memory churn
caused by all sorts of insane temporary object creation. I finally
got fed up with watching the GC go mad while debugging the new
streaming lib, so after a few days of profiling, tweaking, and
tuning, the ugliest parts are cleaned up.
The bad one is a bugfix for how some tunnel routed messages are
handled - there were some situations where a message was sent
directly to the targeted router rather than tunnel routed prior to
delivery, which could be exploited by an adversary who can do a
little coding. We now properly tunnel route when in doubt.
That may sound good, but the 'bad' part is that it means that there's
going to be some increased latency due to the additional hops, though
these are hops that needed to be used anyway.
There are other debugging activities going on in the core as well, so
there hasn't been an official release yet - CVS HEAD is 0.4.1.3-8.
In the next few days we'll probably have a 0.4.1.4 release, just to
get all that stuff cleared up. It won't contain the new streaming
lib, of course.
[1] <a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD</a>
* 3) Streaming lib
Speaking of the streaming lib, there has been a lot of progress here,
and the side by side comparison of the old and new libs are looking
good. However, there is still work to be done, and as I said last
time, we're not going to rush it out the door. That does mean that
the roadmap has slipped, likely in the range of 2-3 weeks. More
details when they're available.
* 4) mail.i2p progress
Lots of new stuff this week - working in and out proxies! See
www.postman.i2p for more information.
* 5) BT progress
There has been a flurry of activity regarding porting a BitTorrent
client as of late, as well as updating some tracker settings.
Perhaps we can get some updates from those involved during the
meeting.
* 6) ???
Thats it for me. Sorry for the delay, I forgot about that whole
daylight savings thingamabob. Anyway, see y'all in a few.
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQYf9PBpxS9rYd+OGEQIoGQCgvDKydGRT42tO9bwWutAwnoolpj0AoNyX
Z1ThyrjEZjAttC/wChPN43aD
=SJDa
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/11/02/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-11-02
===============================
.. raw:: html
:file: blog/2004/11/02/status.html

59
i2p2www/blog/2004/11/09/status.html Normal file
View File

@@ -0,0 +1,59 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey everyone, weekly update time
* Index:
1) 0.4.1.4
2) Streaming lib
3) BT progress
4) addressbook.py
5) ???
* 1) 0.4.1.4
The other day we pushed out a new patch update, and 2/3rds of the
network has upgraded so far - thanks! Reports have been positive,
including lower CPU usage and less failures, along side lower memory
usage. The network as a whole has grown a bit, staying consistently
in the upper 70s/low 80s as well, which is a good healthy number for
the time being.
* 2) Streaming lib
Lets see if I can say the same thing three weeks in a row... Lots of
progress, more details when they're available :)
* 3) BT progress
The BitTorrent port has been making leaps and bounds as of late - the
other day I installed it and was able to do a swarming transfer
between multiple peers entirely through I2P! Perhaps duck can give
us an update during the meeting?
* 4) addressbook.py
Ragnarok has put together a python app which lets you subscribe to
other people's hosts files, importing and merging new entries with
your own. This gives us a base implementation of an addressbook
based naming system with locally unique, human readable, and secure
names! Perhaps we can get Ragnarok to fill us in on further details
in the meeting?
* 5) ???
Thazzit... sorry for the delay, woke up 5 minutes ago :) see y'all
shortly
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQZE0XxpxS9rYd+OGEQIsbACg35hp/g9FIrOlDj5Dy4dOMR91//kAn0Ou
iHMiSnKD18OhLH6P91TLfSSv
=qbBT
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/11/09/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-11-09
===============================
.. raw:: html
:file: blog/2004/11/09/status.html

74
i2p2www/blog/2004/11/16/status.html Normal file
View File

@@ -0,0 +1,74 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, its tuesday again
* Index
1) Congestion
2) Streaming
3) BT
4) ???
* 1) Congestion
I know, I'm breaking the habit of naming point 1 &quot;Net status&quot;, but
this week &quot;congestion&quot; seems appropriate. The network itself has
been doing pretty well, but as the bittorrent usage increased, things
started getting more and more clogged up, leading to an essential
congestion collapse [1].
This was expected, and only reinforces our plan - get the new
streaming lib out there, and revamp our tunnel management so we have
sufficient data about peers to use when our fast peers fail. There
were some other factors in play in the recent network problems, but
the bulk can be traced to the congestion increase and resulting
tunnel failures (which in turn caused all sorts of wild peer
selection).
[1] <a rel="nofollow" href="http://en.wikipedia.org/wiki/Congestion_collapse">http://en.wikipedia.org/wiki/Congestion_collapse</a>
* 2) Streaming
There has been a lot of progress with the streaming lib, and I've got
a squid proxy rigged up to it through the live net that I've been
using it frequently for my normal web browsing. With mule's help,
we've been hammering the streams pretty hard too by piping frost and
FUQID through the network (my god, I never realized how abusive frost
was before doing this!) A few significant longstanding bugs have
been tracked down this way, and some tweaks to help control massive
numbers of connections have been added.
Bulk streams are working great too, with both slow start and
congestion avoidance, and the quick send/reply connections (ala HTTP
get+response) are doing exactly what they should.
I expect we'll draft some volunteers to try deploying it further over
the next few days, and hopefully get us to the 0.4.2 level soon. I
don't want to say it'll be so good that it does your dishes, and I'm
sure there'll be bugs that slip through, but it does look promising.
* 3) BT
Barring the recent network troubles, the i2p-bt port has been making
leaps and bounds. I know a few people have pulled down over a GB of
data through it, and performance has been as expected (due to the old
streaming lib, ~4KBps per peer in the swarm). I try to listen in on
the work being discussed in the #i2p-bt channel - perhaps duck could
give us a summary in the meeting?
* 4) ???
Thazzit from me for now. See y'all in the meeting in a few minutes.
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQZpoZBpxS9rYd+OGEQJ7hQCgm635Z/qWpcfDiKQE2JO2Q3eAR/UAn2yQ
ZEawa8wEMLl1tz/uk4BTENkb
=ZS5w
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/11/16/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-11-16
===============================
.. raw:: html
:file: blog/2004/11/16/status.html

116
i2p2www/blog/2004/11/23/status.html Normal file
View File

@@ -0,0 +1,116 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, time for a status update
* Index:
1) Net status
2) Streaming lib
3) 0.4.2
4) Addressbook.py 0.3.1
5) ???
* 1) Net status
After last week's 2-3 day stint of things being pretty congested, the
network has come back on track (likely because we stopped stress
testing the bittorrent port ;). The network has been pretty reliable
since then - we do have a few routers that have been up and running
for 30-40+ days, but IRC connections have still had their occational
bumps. On the other hand...
* 2) Streaming lib
For the last week or so, we've been doing a lot more live testing of
the streaming lib on the network and things have been looking pretty
good. Duck set up a tunnel with it that people could use to access
his IRC server, and over the course of a few days, I only had two
unnecessary disconnects (which helped us track down some bugs).
We've also had an i2ptunnel instance pointing at a squid outproxy
that people have been trying out, and both the throughput, latency,
and reliability are much improved when compared to the old lib, which
we did side by side.
All in all, the streaming lib looks to be in good enough shape for a
first release. There are a few things left not yet completed, but
its a significant improvement on the old lib, and we've got to give
you a reason to upgrade later, right? ;)
Actually, just to tease you (or perhaps inspire you to come up with
some solutions), the main things I see coming down the line for the
streaming lib are:
= some algorithms to share congestion and RTT information across
streams (per target destination? per source destination? for
all of the local destinations?)
= further optimizations for interactive streams (most of the focus
in the current implementation is on bulk streams)
= more explicit use of the new streaming lib's features in
I2PTunnel, reducing the per-tunnel overhead.
= client level bandwidth limiting (in either or both directions
on a stream, or possibly shared across multiple streams). This
would be in addition to the router's overall bandwidth limiting,
of course.
= various controls for destinations to throttle how many streams
they accept or create (we have some basic code, but largely
disabled)
= access control lists (only allowing streams to or from certain
other known destinations)
= web controls and monitoring the health of the various streams,
as well as the ability to explicitly close or throttle them
Y'all can probably come up with some other things too, but thats
just a brief list of things I'd love to see in the streaming lib,
but won't hold up the 0.4.2 release for. If anyone is interested
in any of those, please, lemmie know!
* 3) 0.4.2
So, if the streaming lib is in good shape, when are we gong to have
the release? The current plan is to push it out the door by the
end of the week, maybe even as soon as tomorrow. There are a few
other things going on that I want to get sorted first, and of
course those need to be tested, yadda yadda yadda.
The big change in the 0.4.2 release will of course be the new
streaming lib. From an API perspective, it is identical to the
old lib - I2PTunnel and SAM streams automatically use it, but from
a packet perspective, it is *not* backwards compatible. This leaves
us with an interesting dilemma - there is nothing within I2P
requiring us to make 0.4.2 into a manditory upgrade, however people
who don't upgrade won't be able to use I2PTunnel - no eepsites, no
IRC, no outproxy, no email. I don't want to alienate our long time
users by forcing them to upgrade, but I also don't want to alienate
them by having everything useful break ;)
I'm open to being convinced either way - it would be easy enough to
change a single line of code so that the 0.4.2 release won't talk to
the older releases, or we could just let it be and have people
upgrade whenever they go to the website or forum to bitch about
everything being broken. What do y'all think?
* 4) Addressbook.py 0.3.1
Ragnarok has come out with a new patch release for his address book
app - see <a rel="nofollow" href="http://ragnarok.i2p/">http://ragnarok.i2p/</a> for more info (or perhaps he can give
us an update in the meeting?)
* 5) ???
I know there's a lot more activity going on - with the bittorrent
port, susimail, slacker's new hosting service, among other things.
Anyone have anything else to bring up? If so, swing on by the
meeting in ~30m in #i2p on the usual IRC servers!
=jr
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQaOeJxpxS9rYd+OGEQKUCwCg601Jw+mvt+rx0MMMOcNaqlGBExQAoIp7
pfi+wfwTumipVNuMFPUm39TK
=VwGu
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/11/23/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-11-23
===============================
.. raw:: html
:file: blog/2004/11/23/status.html

100
i2p2www/blog/2004/11/30/status.html Normal file
View File

@@ -0,0 +1,100 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all
* Index
1) 0.4.2 and 0.4.2.1
2) mail.i2p
3) i2p-bt
4) eepsites
5) ???
* 1) 0.4.2 and 0.4.2.1
Since we finally pushed out 0.4.2, the network's reliability and
throughput shot up for a while, until we ran into the brand new
bugs we created. IRC connections for most people are lasting
for hours on end, though for some who have run into some of the
problems, its been a bumpy ride. There have been a slew of
fixes [1] though, and later on tonight or early tomorrow we'll
have a new 0.4.2.1 release ready for download.
[1] <a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD</a>
* 2) mail.i2p
Earlier today I got slipped a note from postman saying he had
some things he wanted to discuss - for more info, see the
meeting logs (or if you're reading this before the meeting,
swing on by).
* 3) i2p-bt
One of the downsides of the new release is that we're running into
some trouble with the i2p-bt port. Some of the problems have been
identified found and fixed in the streaming lib, but further work
is necessary to get it where we need it to be.
* 4) eepsites
There has been some discussion over the months on the list, in the
channel, and on the forum about some problems with how eepsites
and the eepproxy work - recently some have mentioned problems with
how and what headers are filtered, others have brought up the
dangers of poorly configured browsers, and there's also DrWoo's
page [2] summarizing many of the risks. One particularly note
worthy event is the fact that some people are actively working on
applets that will hijack the user's computer if they do not
disable applets. (SO DISABLE JAVA AND JAVASCRIPT IN YOUR BROWSER)
This, of course, leads to a discussion of how we can secure
things. I've heard suggestions of building our own browser or
bundling one with preconfigured secure settings, but lets be
realistic - thats a lot more work than anyone here is going to
bite into. However, there are three other camps:
1) Use a fascist HTML filter and tie it in with the proxy
2) Use a fascist HTML filter as part of a script that fetches
pages for you
3) Use a secure macro language
The first is pretty much like we have now, except we filter the
content rendered through something like muffin or freenet's
anonymity filter. The downside here is that it still exposes
HTTP headers so we'd have to anonymize the HTTP side as well.
The second is much like you can see on <a rel="nofollow" href="http://duck.i2p/">http://duck.i2p/</a> with the
CGIproxy, or alternately as you can see in freenet's fproxy. This
takes care of the HTTP side as well.
The third has its benefits and drawbacks - it lets us use much
more compelling interfaces (as we can safely use some known safe
javascript, etc), but has the downside of backwards
incompatability. Perhaps a merge of this with a filter, allowing
you to embed the macros in filtered html?
Anyway, this is an important development effort and addresses one
of the most compelling uses of I2P - safe and anonymous
interactive websites. Perhaps someone has some other ideas or
info as to how we could get what is needed?
[2] <a rel="nofollow" href="http://brittanyworld.i2p/browsing/">http://brittanyworld.i2p/browsing/</a>
* 5) ???
Ok, I'm running late for the meeting, so I suppose I should sign
this and send it on its way, 'eh?
=jr
[lets see if I get gpg to work right...]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBrOBZGnFL2th344YRArtBAJ9YhRvP3MczO96gi4Xwnowie55HlACgzlO3
1uyX1xgZLboelTOSdermS+Q=
=e5Xv
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/11/30/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-11-30
===============================
.. raw:: html
:file: blog/2004/11/30/status.html

58
i2p2www/blog/2004/12/07/status.html Normal file
View File

@@ -0,0 +1,58 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all
* Index
1) 0.4.2.3
2) i2p-bt
3) #idlerpg
4) ???
jrandom said he'd probably not make it to the meeting today,
so we have to do it without him
* 1) 0.4.2.3
Expected to be released tomorrow or thursday. It contains a
lot of fixes [1], a lot are SAM related.
[1] <a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD</a>
* 2) i2p-bt
Yesterday a new version of the i2p bittorrent client was
released [2], version 0.1.3. It seems to work better than
before, also thanks due to the SAM fixes, though there is
still some weird behaviour.
There have been several requests to improve the GUI.
I, duck, have never done any GUI coding in Python, so it is
not likely that this will happen soon; hopefully someone
jumps in to assist here.
[2] <a rel="nofollow" href="http://forum.i2p.net/viewtopic.php?t=192">http://forum.i2p.net/viewtopic.php?t=192</a>
* 3) Idle RPG - #idlerpg
Some fun RPG which you can join [3] while you are on IRC
anyway, you don't have to do anything besides idleing.
[3] <a rel="nofollow" href="http://duck.i2p/idlerpg/">http://duck.i2p/idlerpg/</a>
* 4) ???
See you in the meeting at 21:00 UTC.
= duck
[PGP signature might be invalid due to line wrapping]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFBthZwHV6vOQfY4WwRAinQAJ9PMcQTF8HKb/qVQg92YDTkOyMNNgCffYVF
YTCLve/isV8C5myLdWTNiBA=
=JstM
-----END PGP SIGNATURE-----</pre><pre>_______________________________________________
i2p mailing list
i2p-Po2eaMWI3R0@xxxxxxxxxxxxxxxx
<a rel="nofollow" href="http://i2p.dnsalias.net/mailman/listinfo/i2p">http://i2p.dnsalias.net/mailman/listinfo/i2p</a>
</pre>

6
i2p2www/blog/2004/12/07/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-12-07
===============================
.. raw:: html
:file: blog/2004/12/07/status.html

100
i2p2www/blog/2004/12/14/status.html Normal file
View File

@@ -0,0 +1,100 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, time for the weekly status notes
* Index
1) Net status
2) mail.i2p
3) roadmap
4) i2pcontent
5) i2p-bt
6) ???
* 1) Net status
The 0.4.2.3 release included a whole slew of fixes and the net
handled things pretty well. Over time we ran into a few long
standing peer selection and overload problems on duck's irc server
though, but after some patches that seems to have recovered nicely.
There are a few key modifications that have been made since 0.4.2.3
that we'll be rolling out into a 0.4.2.4 release fairly soon:
= bandwidth-based tunnel throttling
= reenabling (with some tweaks) the probabalistic dropping of
messages under heavy congestion
= various profiling and ranking fixes
= some time sync related updates.
That last one is worth a bit more discussion, as it relates to
something we've been seeing over the last day or two. For some
reason, we have had a small portion of the network somehow get their
clocks skewed by 5 minutes. We've recently improved the safe and
automatic healing of the time synchronization, and there's also
some new code to proactively kick out peers whose clocks skew after
the connection is established. These are only partial solutions
though - in the long run, we need secure NTP synchronization (or at
least synchronization within our 60s margin of error). Before you
say it, let me just reiterate that I'd love to get rid of the clock
synchronization issue, and if you can come up with a way to do so
securely, we'll do so.
In any case, with the various fixes in place I do expect we'll have
a new 0.4.2.4 release in the next day or three, so keep your ears to
the ground.
* 2) mail.i2p
I've been hearing some whispering of some neat features coming from
mail.i2p lately, and postman has some things he wants to discuss -
swing on by the meeting and see what's up!
* 3) roadmap
No Dorothy, we aren't going to have the 1.0 release this month.
I've updated <a rel="nofollow" href="http://www.i2p.net/roadmap">http://www.i2p.net/roadmap</a> with both revised content
and a more conservative schedule. The old 0.4.3 release is being
placed as 0.5 and 0.4.4 is being placed as 0.6, since they're both
pretty hefty updates. You'll also note one of 0.6's new items -
&quot;Basic content distribution infrastructure&quot;. Thats...
* 4) I2PContent
Frosk has been posting [1] up some really cool ideas for a content
distribution network on top of I2P, merging the old MyI2P with the
original P2P network, the only one that can push terrabytes of data
around without batting an eye and has a 20+ year track record -
Usenet. Frosk's work on this is looking pretty exciting, so check
out the posts on his blog and get in touch with him if you want to
help!
[1] <a rel="nofollow" href="http://frosk.i2p/">http://frosk.i2p/</a>
* 5) i2p-bt
As announced [2] last week, duck &amp; gang have claimed the swarming
file transfer bounty [3] with their port [4] of the original
BitTorrent to I2P! See the announcement for more details.
[2] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p/2004-December/000517.html">http://dev.i2p.net/pipermail/i2p/2004-December/000517.html</a>
[3] <a rel="nofollow" href="http://www.i2p.net/bounties">http://www.i2p.net/bounties</a>
[4] <a rel="nofollow" href="http://duck.i2p/i2p-bt/">http://duck.i2p/i2p-bt/</a>
* 6) ???
I'm sure there are thing that I'm overlooking and there's much left
unsaid, so swing on by the meeting tonight and discuss things
further.
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBv1LSGnFL2th344YRAsJ9AJ9by/2pRJs0dtkJF9A+qezpSRgPHQCgzTEz
vL+gi2piiZq3aup7iyN/wRY=
=3w0k
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/12/14/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-12-14
===============================
.. raw:: html
:file: blog/2004/12/14/status.html

110
i2p2www/blog/2004/12/21/status.html Normal file
View File

@@ -0,0 +1,110 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ev'nin folks, time for our status update
* Index
1) 0.4.2.4 &amp; 0.4.2.5
2) 0.5 strategy
3) naming
4) eepsite roundup
5) ???
1) 0.4.2.4 &amp; 0.4.2.5
With last week's 0.4.2.4 release, we saw the deployment of some new
load balancing algorithms to throttle tunnel participation based on
actual bandwidth usage, along side peer profiling updates to select
peers better through a wider sample of data. This has done pretty
well at both choking tunnel participation when necessary and finding
good peers when possible.
Another major update in that release was a change to how we verify
time synchronization - rather than just checking the time sync once
during connection establishment, peers now periodically send
messages to each other with their current time, and if the time
received is too far skewed, the connection is dropped. This has
helped kick a few routers who were skewing off the net until they
recovered (which is good), and the vast majority of peers have been
quite close to 'correct' (you can see the clock skew on the
/oldconsole.jsp page)
With that, the network has been performing pretty well, but we were
still seeing the occational bulk disconnect. After some debugging
we tracked down an unintentional and wholely unnecessary DNS lookup
that occurred whenever a router sent a message to a peer who has a
hostname specified. This not only wasted time, but it wasted time
within the jobqueue - essentially injecting a whole lot of lag for
no reason. With that lookup removed, the router handled much
better under heavily congested situations, but we were still seeing
those occational bulk disconnects. After digging around in the
stats and logging, we came up with a plausible theory that explains
why those disconnects have been occurring - blaming them almost
entirely on those DNS lookups. To test that theory (and to deploy
some other goodies), we pushed out the 0.4.2.5 release this
afternoon.
We'll see how it goes.
* 2) 0.5 strategy
As the roadmap [1] says, the next planned release is 0.5, including
a revised tunnel pool and encryption/id technique. Avoiding a
big explanation (see [2], [3], [4], and a tiny bit of [5]), we will
do this in two stages - first revamp the tunnel pooling and
push that out as an interim release, debugging what is necessary,
then revamp the encryption/id stuff, pushing that out as 0.5. Oh,
and of course, once the algorithms for the pooling and encryption
updates are in pretty good shape, they'll be posted up here and on
the website for review.
Along the way though, there will probably be small bugfix releases
unrelated to the 0.5 stuff, but I don't have any specifically
planned.
[1] <a rel="nofollow" href="http://www.i2p.net/roadmap">http://www.i2p.net/roadmap</a>
[2] <a rel="nofollow" href="http://www.i2p.net/todo#tunnelId">http://www.i2p.net/todo#tunnelId</a>
[3] <a rel="nofollow" href="http://www.i2p.net/todo#ordering">http://www.i2p.net/todo#ordering</a>
[4] <a rel="nofollow" href="http://www.i2p.net/todo#tunnelLength">http://www.i2p.net/todo#tunnelLength</a>
[5] <a rel="nofollow" href="http://www.i2p.net/todo#batching">http://www.i2p.net/todo#batching</a>
* 3) naming
Yikes, now that I think about it, I really don't want to talk
about naming yet - just download Ragnarok's latest addressbook
app (2.0.1) from <a rel="nofollow" href="http://ragnarok.i2p/">http://ragnarok.i2p/</a>, check out susi's web
based manager at <a rel="nofollow" href="http://susi.i2p/susidns/manager">http://susi.i2p/susidns/manager</a>, and dig
through the stats at <a rel="nofollow" href="http://orion.i2p/">http://orion.i2p/</a> and
<a rel="nofollow" href="http://susi.i2p/susisworld.html">http://susi.i2p/susisworld.html</a>
* 4) eepsite roundup
There have been some notable developments on various eepsites worth
mentioning:
= <a rel="nofollow" href="http://frosk.i2p/">http://frosk.i2p/</a> - I2PContent doc updates
= <a rel="nofollow" href="http://orion.i2p/">http://orion.i2p/</a> - new form to submit your keys to
= <a rel="nofollow" href="http://piespy.i2p/">http://piespy.i2p/</a> - neat graphs of the irc channels
= <a rel="nofollow" href="http://forum.fr.i2p/">http://forum.fr.i2p/</a> - french language forum
= <a rel="nofollow" href="http://pastebin.i2p/">http://pastebin.i2p/</a> - stop flooding the channels!
Of course, there have also been updates to other sites as well,
plus some other new sites - check orion.i2p and sort the list by
'last updated' to review (or just go to 'em all ;)
5) ???
I know there's lots more going on, so please, swing on by the
meeting in a few minutes and we can chat 'bout stuff.
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFByItjGnFL2th344YRAmmOAKD+HxEAK+dqseq8ZCO5pjvW4EKImQCgkfwX
1KM+uQo7D6BjHAA99DwVyS0=
=/T/b
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/12/21/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-12-21
===============================
.. raw:: html
:file: blog/2004/12/21/status.html

56
i2p2www/blog/2004/12/28/status.html Normal file
View File

@@ -0,0 +1,56 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, time for a quick update on things
* Index
1) 0.4.2.5
2) 0.5
3) ???
* 1) 0.4.2.5
The 0.4.2.5 release has gone pretty well - most people updated
within a day or two (thanks!) and there haven't really been any
show stoppers since - IRC has been more reliable than usual,
transfer rates have improved, tunnel failures reduced, and the
ambient network load has shrunk so much that people have been
complaining.
Its not all motherhood and apple pie though, and I've been tracking
down some intermittent problems with the sdk and streaming lib where
connections are both failing prematurely and taking longer than they
should be to propogate messages. I know there's the law of
diminishing returns going on here, and I'm not going to keep
tweaking and tweaking until its 100% perfect, but I believe there
are still some measurable improvements left to be made.
* 2) 0.5
Luckily (?), I had some hardware failures last week which bumped me
offline for a few days, giving me time to get out the pen &amp; paper to
work through more details of the 0.5 tunnel management code.
Nothing substantial to report here yet though.
* 3) ???
Very brief summary, I know, but most of the work over the last week
has been on paper. As mentioned [1] on the list, Connelly is
running an intersection attack against some eepsites, so once
there's some data to report on, I'm sure he'll give us the scoop.
Anyone else have anything to bring up - if so, swing on by the
meeting.
[1] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p/2004-December/000534.html">http://dev.i2p.net/pipermail/i2p/2004-December/000534.html</a>
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFB0cgrGnFL2th344YRApCsAJ9lSLbrhNdPuGHJssopyfXEJGpdDQCeMdPd
c9O5fcXfOJ54OuM7vPhHBQU=
=GAV/
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2004/12/28/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2004-12-28
===============================
.. raw:: html
:file: blog/2004/12/28/status.html

114
i2p2www/blog/2005/01/04/status.html Normal file
View File

@@ -0,0 +1,114 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, time for our first weekly status notes of 2005
* Index
1) Net status
2) 0.4.2.6
3) 0.5
4) jabber @ chat.i2p
5) ???
* 1) Net status
Over the last week, things have been pretty interesting on the net -
on nye, there were some comments posted to a popular website talking
about i2p-bt and we've had a small burst of new users. At the
moment there are between 120-150 routers on the net, though that
peaked at 160 a few days ago. The network held its own though, with
high capacity peers picking up the excess load without much
disruption to other peers. Some users running without bandwidth
limits on really fast links have reported throughput of 2-300KBps,
while those with less capacity use the usual low 1-5KBps.
I think I remember Connelly mentioning that he was seeing 300+
different routers over the course of a few days after new years, so
there has been significant churn. On the other hand, we now have a
steady 120-150 users online, unlike the previous 80-90, which is a
reasonable increase. We still do *not* want it to grow too much
yet though, as there are known implementation issues that still need
to be done. Specifically, until the 0.6 release [1], we're going to
want to stay below 2-300 peers to keep the number of threads at a
reasonable level. However, if someone wants to help out
implementing the UDP transport, we can get there much faster.
In the last week, I've watched the stats put out by the i2p-bt
trackers and there have been gigs of large files transferred, with
some reports of 80-120KBps. IRC has had more bumps than usual
since those comments were posted on that website, but its still on
the order of hours between disconnect. (from what I can tell, the
router that irc.duck.i2p is on has been running pretty close to its
bandwidth limit, which would explain things)
[1] <a rel="nofollow" href="http://www.i2p.net/roadmap#0.6">http://www.i2p.net/roadmap#0.6</a>
* 2) 0.4.2.6
There have been some fixes and new features added to CVS since the
0.4.2.5 release that we're going to want to roll out soon,
including reliability fixes for the streaming lib, improved
resiliance to IP address change, and the bundling of ragnarok's
addressbook implementation.
If you haven't heard of the addressbook or haven't used it, the
short story is that it will magically update your hosts.txt file
by periodically fetching and merging changes from some anonymously
hosted locations (default being <a rel="nofollow" href="http://dev.i2p/i2p/hosts.txt">http://dev.i2p/i2p/hosts.txt</a> and
<a rel="nofollow" href="http://duck.i2p/hosts.txt">http://duck.i2p/hosts.txt</a>). You won't need to change any files,
touch any configuration, or run any extra applications - it'll be
deployed inside the I2P router as a standard .war file.
Of course, if you *do* want to get down and dirty with the
addressbook, you are more than welcome to - see Ragnarok's site [2]
for the details. People who already have the addressbook deployed
in their router will need to do a little tap dancing during the
0.4.2.6 upgrade, but it'll work with all your old config settings.
[2] <a rel="nofollow" href="http://ragnarok.i2p/">http://ragnarok.i2p/</a>
* 3) 0.5
Numbers, numbers, numbers! Well, as I've said before, the 0.5
release will be revamping how the tunnel routing works, and progress
is being made on that front. For the last few days I've been
implementing the new encryption code (and unit tests), and once
they're working I'll post up a doc describing my current thoughts on
how, what, and why the new tunnel routing will operate. I'm getting
the encryption implemented for it now instead of later so that
people can review what it means in a concrete sense, as well as find
problems areas and suggestions for improvement. I'm hoping to have
the code working by the end of the week, so maybe there'll be more
docs posted this weekend. No promises though.
* 4) jabber @ chat.i2p
jdot has started up a new jabber server, and it seems to work pretty
well for both one on one conversations and group chat. check out
the info on the forum [3]. the i2p dev discussion channel will
still be the irc #i2p, but its always nice to have alternatives.
[3] <a rel="nofollow" href="http://forum.i2p.net/viewtopic.php?t=229">http://forum.i2p.net/viewtopic.php?t=229</a>
* 5) ???
Ok, thats about all I have to mention at the moment - I'm sure
there's lots more going on that other people want to bring up
though, so swing on by the meeting in 15m @ the usual place [4] and
tell us whats up!
=jr
[4] irc://irc.{duck,baffled}.i2p/#i2p
irc://iip/#i2p
irc://irc.freenode.net/#i2p
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFB2wGXGnFL2th344YRAuAkAJwPh8frN6Caof0unduGzijXFyFDnwCfXD/8
ZQXQmqk6EIx184r2Zi7poZg=
=+oCL
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/01/04/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-01-04
===============================
.. raw:: html
:file: blog/2005/01/04/status.html

131
i2p2www/blog/2005/01/11/status.html Normal file
View File

@@ -0,0 +1,131 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, time for the weekly update
* Index
1) Net status
2) 0.5 progress
3) 0.6 status
4) azneti2p
5) fbsd
6) hosts.txt as WoT
7) ???
* 1) Net status
Overall the net is handling itself well, though we had some problems
with one of the irc servers being offline and my outproxy acting up.
However, the other irc server was (and still is) around (though at
the moment doesn't have CTCP disabled - see [1]), so we were able to
satiate our need for irc :)
[1] <a rel="nofollow" href="http://ugha.i2p/HowTo/IrcAnonymityGuide">http://ugha.i2p/HowTo/IrcAnonymityGuide</a>
* 2) 0.5 progress
There's progress, ever onwards! Ok, I suppose I should get into a
little more detail than that. I've finally got the new tunnel
routing crypto implemented and tested (yay!), but during some
discussions we found a place where there could be one level of
anonymity leak, so its being revised (the first hop would have
known they were the first hop, which is Bad. but really really
easy to fix). Anyway, I hope to get the docs and code on that
updated and posted soon, and docs on the rest of the 0.5 tunnel
operation / pooling / etc posted later. More news when there's
more news.
* 3) 0.6 status
(what!?)
Mule has begun investigations into the UDP transport, and we've
been mining zab for his experiences with limewire's UDP code.
Its all very promising, but much work to be done (and still
several months out on the roadmap [2]). Got some inspiration or
suggestions? Get involved and help focus it towards what needs to
be done!
[2] <a rel="nofollow" href="http://www.i2p.net/roadmap#0.6">http://www.i2p.net/roadmap#0.6</a>
* 4) azneti2p
I almost wet my pants when I got the info, but it looks like the
folks at azureus have written up an I2P plugin, allowing both
anonymous tracker usage and anonymous data comm! Multiple
torrents work within a single I2P destination too, and it uses
the I2PSocket directly, allowing tight integration with the
streaming lib. The azneti2p plugin is still in the early stages
with this 0.1 release, and there are lots of optimizations and ease
of use improvements coming down the pipe, but if you're up for
getting your hands dirty, swing by i2p-bt on the i2p irc networks
and get in on the fun :)
For the adventurus types, get the latest azureus [3], check their
i2p howto [4], and snag the plugin [5].
[3] <a rel="nofollow" href="http://azureus.sourceforge.net/index_CVS.php">http://azureus.sourceforge.net/index_CVS.php</a>
[4] <a rel="nofollow" href="http://azureus.sourceforge.net/doc/AnonBT/i2p/I2P_howto.htm">http://azureus.sourceforge.net/doc/AnonBT/i2p/I2P_howto.htm</a>
[5] <a rel="nofollow" href="http://azureus.sourceforge.net/plugin_details.php?plugin=azneti2p">http://azureus.sourceforge.net/plugin_details.php?plugin=azneti2p</a>
duck has been taking heroic measures to keep compatability with
i2p-bt, and there is frantic hacking in #i2p-bt as I type this, so
keep an eye out for a new i2p-bt release Real Soon Now.
* 5) fbsd
Thanks to the work of lioux, there's now a freebsd ports entry for
i2p [6]. While we aren't really looking to have lots of
distro-specific installs out there, he promises to keep it updated
when we give sufficient notice for new release. This should be
helpful for fbsd-current folks - thanks lioux!
[6] <a rel="nofollow" href="http://www.freshports.org/net/i2p/">http://www.freshports.org/net/i2p/</a>
* 6) hosts.txt as WoT
Now that the 0.4.2.6 release has bundled in Ragnarok's addressbook,
the process of keeping your hosts.txt populated with new entries is
in every user's control. Not only that, but you can view the
addressbook subscriptions as a poor-man's web of trust - you import
new entries from a site you trust to introduce you to new
destinations (defaults being dev.i2p and duck.i2p).
With this capacity comes a whole new dimension - the ability for
people to choose what sites to essentially link to in their
hosts.txt and which ones not to. While there is a place for the
public free-for-all that has occurred in the past, now that the
naming system is not just in theory but in practice fully
distributed, people will need to figure out their own policies on
publishing other people's destinations.
The important part behind the scenes here is that this is a learning
opportunity for the I2P community. Before, both gott and I were
trying to help push the naming issue by publishing gott's site as
jrandom.i2p (he asked for that site first - I did not, and have no
control whatsoever as to the contents of that URL). Now we may
begin to explore how we are going to deal with sites not listed in
the <a rel="nofollow" href="http://dev.i2p.net/i2p/hosts.txt">http://dev.i2p.net/i2p/hosts.txt</a> or on forum.i2p. Not being
posted on those locations doesn't prevent in any way a site from
operating - your hosts.txt is just your local address book.
Anyway, enough babbling, I just wanted to put people on notice so
we can all see what is to be done.
* 7) ???
Yowza, thats a lot of stuff. Busy week, and I don't forsee things
slowing down anytime soon. So, swing on by the meeting in a few
minutes and we can talk about stuff.
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFB5D2EGnFL2th344YRAoMnAJsHxgRyB3eydlqKiCy54CYzRCEbsQCfRWV0
ItUMfG4sTnmRKk5m2u9Yxjg=
=cJJx
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/01/11/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-01-11
===============================
.. raw:: html
:file: blog/2005/01/11/status.html

137
i2p2www/blog/2005/01/18/status.html Normal file
View File

@@ -0,0 +1,137 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, weekly update time
* Index
1) Net status
2) 0.5
3) i2pmail.v2
4) azneti2p_0.2
5) ???
* 1) Net status
Hmm, not much to report here - things still work as they did last
week, size of the net is still pretty similar, perhaps a little
larger. Some neat new sites are popping up - see the forum [1]
and orion [2] for details.
[1]<a rel="nofollow" href="http://forum.i2p.net/viewforum.php?f=16">http://forum.i2p.net/viewforum.php?f=16</a>
[2]<a rel="nofollow" href="http://orion.i2p/">http://orion.i2p/</a>
* 2) 0.5
Thanks to the help of postman, dox, frosk, and cervantes (and
everyone who tunneled data through their routers ;), we've
collected a full day's worth of message size stats [3]. There are
two sets of stats there - height and width of the zoom. This was
driven by the desire to explore the impact of different message
padding strategies on the network load, as explained [4] in one of
the drafts for the 0.5 tunnel routing. (ooOOoo pretty pictures).
The scary part about what I found digging through those was that by
using some pretty simple hand-tuned padding breakpoints, padding to
those fixed sizes would still ended up with over 25% of the
bandwidth wasted. Yeah, I know, we're not going to do that.
Perhaps y'all can come up with something better by digging through
that raw data.
[3] <a rel="nofollow" href="http://dev.i2p.net/~jrandom/messageSizes/">http://dev.i2p.net/~jrandom/messageSizes/</a>
[4] <a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/</a>
tunnel.html?rev=HEAD#tunnel.padding
Actually, that [4] link leads us into the state of the 0.5 plans for
the tunnel routing. As Connelly posted [5], there has been a lot of
discussion lately on IRC about some of the drafts, with polecat,
bla, duck, nickster, detonate and others contributing suggestions
and probing questions (ok, and snarks ;). After a little more than
a week, we came across a potential vulnerability with [4] dealing
with an adversary who was somehow able to take over the inbound
tunnel gateway who also controlled one of the other peers later in
that tunnel. While in most cases this by itself wouldn't expose the
endpoint, and would be probabalistically hard to do as the network
grows, it still Sucks (tm).
So in comes [6]. This gets rid of that issue, allows us to have
tunnels of any length, and solves world hunger [7]. It does open
another issue where an attacker could build loops in the tunnel, but
based on a suggestion [8] Taral made last year regarding the session
tags used on ElGamal/AES, we can minimize the damage done by using
a series of synchronized pseudorandom number generators [9].
[5] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p/2005-January/000557.html">http://dev.i2p.net/pipermail/i2p/2005-January/000557.html</a>
[6] <a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/</a>
tunnel-alt.html?rev=HEAD
[7] guess which statement is false?
[8] <a rel="nofollow" href="http://www.i2p.net/todo#sessionTag">http://www.i2p.net/todo#sessionTag</a>
[9] <a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/</a>
tunnel-alt.html?rev=HEAD#tunnel.prng
Don't worry if the above sounds confusing - you're seeing the
innards of some gnarly design issues being wrung out in the open.
If the above *doesnt* sound confusing, please get in touch, as we're
always looking for more heads to hash through this stuff :)
Anyway, as I mentioned on the list [10], next up I'd like to get the
second strategy [6] implemented to hash through the remaining
details. The plan for 0.5 is currently to get all of the backwards
incompatible changes together - the new tunnel crypto, etc - and
push that as 0.5.0, then as that settles on the net, move on to the
other parts of 0.5 [11], such as adjusting the pooling strategy as
described in the proposals, pushing that as 0.5.1. I'm hoping we
can still hit 0.5.0 by the end of the month, but we'll see.
[10] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p/2005-January/000558.html">http://dev.i2p.net/pipermail/i2p/2005-January/000558.html</a>
[11] <a rel="nofollow" href="http://www.i2p.net/roadmap#0.5">http://www.i2p.net/roadmap#0.5</a>
* 3) i2pmail.v2
The other day postman put out a draft plan of action for the next
generation mail infrastructure [12], and it looks bloody cool. Of
course, there are always yet more bells and whistles we can dream
up, but its got a pretty nice architecture in many ways. Check out
what's been doc'ed up so far [13], and get in touch with the postman
with your thoughts!
[12] <a rel="nofollow" href="http://forum.i2p.net/viewtopic.php?t=259">http://forum.i2p.net/viewtopic.php?t=259</a>
[13] <a rel="nofollow" href="http://www.postman.i2p/mailv2.html">http://www.postman.i2p/mailv2.html</a>
4) azneti2p_0.2
As I posted to the list [14], the original azneti2p plugin for
azureus had a serious anonymity bug. The problem was that mixed
torrents where some users are anonymous and others are not, the
anonymous users would contact the non-anonymous users /directly/
rather than through I2P. Paul Gardner and the rest of the azureus
devs were quite responsive and put out a patch right away. The
issue I saw is no longer present in azureus v. 2203-b12 +
azneti2p_0.2.
We haven't gone through and audited the code to review any potential
anonymity issues though, so &quot;use at your own risk&quot; (OTOH, we say the
same about I2P, prior to the 1.0 release). If you're up for it, I
know the azureus devs would appreciate more feedback and bug reports
with the plugin. We'll of course keep people informed if we find
out about any other issues.
[14] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p/2005-January/000553.html">http://dev.i2p.net/pipermail/i2p/2005-January/000553.html</a>
* 5) ???
Lots going on, as you can see. I think thats about all I've got to
bring up, but please swing by the meeting in 40 minutes if there's
something else you'd like to discuss (or if you just want to rant
about the stuff above)
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFB7XCWGnFL2th344YRAmhxAKC9tc+9ocOgu02PBAH1iBEghzpVXQCbBHLB
LFh9H55UFtsLPRFk7hxdv1c=
=0FdX
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/01/18/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-01-18
===============================
.. raw:: html
:file: blog/2005/01/18/status.html

72
i2p2www/blog/2005/01/25/status.html Normal file
View File

@@ -0,0 +1,72 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, quick weekly status update
* Index
1) 0.5 status
2) sam.net
3) gcj progress
4) udp
5) ???
* 1) 0.5 status
Over the past week, there's been a lot of progress on the 0.5 side.
The issues we were discussing before have been resolved, dramatically
simplifying the crypto and removing the tunnel looping issue. The
new technique [1] has been implemented and the unit tests are in
place. Next up I'm putting together more of the code to integrate
those tunnels into the main router, then build up the tunnel
management and pooling infrastructure. After thats in place, we'll
run it through the sim and eventually onto a parallel net to burn it
in before wrapping a bow on it and calling it 0.5.
[1]<a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD</a>
* 2) sam.net
smeghead has put together a new port of the SAM protocol to .net -
c#, mono/gnu.NET compatible (yay smeghead!). This is in cvs under
i2p/apps/sam/csharp/ with nant and other helpers - now all y'all
.net devs can start hacking with i2p :)
* 3) gcj progress
smeghead is definitely on a tear - at last count, with some
modifications the router is compiling under the latest gcj [2] build
(w00t!). It still doesn't work yet, but the modifications to work
around gcj's confusion with some inner class constructs is definitely
progress. Perhaps smeghead can give us an update?
[2] <a rel="nofollow" href="http://gcc.gnu.org/java/">http://gcc.gnu.org/java/</a>
* 4) udp
Not much to say here, though Nightblade did bring up an interesting
set of concerns [3] on the forum asking why we're going with UDP. If
you've got similar concerns or have other suggestions on how we can
address the issues I replied with, please, chime in!
[3] <a rel="nofollow" href="http://forum.i2p.net/viewtopic.php?t=280">http://forum.i2p.net/viewtopic.php?t=280</a>
* 5) ???
Yeah, ok, I'm late with the notes again, dock my pay ;) Anyway, lots
going on, so either swing by the channel for the meeting, check the
posted logs afterwards, or post up on the list if you've got
something to say. Oh, as an aside, I've given in and started up a
blog within i2p [4].
=jr
[4] <a rel="nofollow" href="http://jrandom.dev.i2p/">http://jrandom.dev.i2p/</a> (key in <a rel="nofollow" href="http://dev.i2p.net/i2p/hosts.txt">http://dev.i2p.net/i2p/hosts.txt</a>)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFB9r1VGnFL2th344YRAvb5AJ9+Y5l9JZOo5znrnY2sunAr0lOJzgCghHpy
W/EO4gPSteZWp+rBogWfB3M=
=nnfw
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/01/25/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-01-25
===============================
.. raw:: html
:file: blog/2005/01/25/status.html

73
i2p2www/blog/2005/02/01/status.html Normal file
View File

@@ -0,0 +1,73 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, weekly status time
* Index
1) 0.5 status
2) nntp
3) tech proposals
4) ???
* 1) 0.5 status
There has been lots of progress on the 0.5 front, with a big batch
of commits yesterday. The bulk of the router now uses the new
tunnel encryption and tunnel pooling [1], and it has been working
well on the test network. There are still some key pieces left to
integrate, and the code is obviously not backwards compatible, but
I'm hoping we can do some wider scale deployment sometime next week.
As mentioned before, the initial 0.5 release will provide the
foundation on which different tunnel peer selection/ordering
strategies can operate. We'll start with a basic set of
configurable parameters for the exploratory and client pools, but
later releases will probably include other options for different
user profiles.
[1]<a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD</a>
* 2) nntp
As mentioned on LazyGuy's site [2] and my blog [3], we've got a new
NNTP server up and running on the network, reachable at nntp.fr.i2p.
While LazyGuy has fired up some suck [4] scripts to read in a few
lists from gmane, the content is pretty much of, for, and by I2P
users. jdot, LazyGuy, and myself did some research into what
newsreaders could be used safely, and there seem to be some pretty
easy solutions. See my blog for instructions on running slrn [5]
to do anonymous newsreading and posting.
[2] <a rel="nofollow" href="http://fr.i2p/">http://fr.i2p/</a>
[3] <a rel="nofollow" href="http://jrandom.dev.i2p/">http://jrandom.dev.i2p/</a>
[4] <a rel="nofollow" href="http://freshmeat.net/projects/suck/">http://freshmeat.net/projects/suck/</a>
[5] <a rel="nofollow" href="http://freshmeat.net/projects/slrn/">http://freshmeat.net/projects/slrn/</a>
* 3) tech proposals
Orion and others have put up a series of RFCs for various tech
issues up on ugha's wiki [6] to help flesh out some of the harder
client and app level problems out there. Please use that as the
place to discuss naming issues, updates to SAM, swarming ideas, and
the like - when you post up there, we can all collaborate at our own
place to get a better result.
[6] <a rel="nofollow" href="http://ugha.i2p/I2pRfc">http://ugha.i2p/I2pRfc</a>
* 4) ???
Thats all I have for the moment (good thing too, as the meeting
starts momentarily). As always, post up your thoughts whenever and
wherever :)
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFB/+1+GnFL2th344YRAuF5AKDF/FzxzlKs25B2FRLsmC61KRQjlgCg/YjD
kF6G0CoDu08TvpEtuzuzH9o=
=ewBU
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/02/01/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-02-01
===============================
.. raw:: html
:file: blog/2005/02/01/status.html

106
i2p2www/blog/2005/02/08/status.html Normal file
View File

@@ -0,0 +1,106 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, update time again
* Index
1) 0.4.2.6-*
2) 0.5
3) i2p-bt 0.1.6
4) fortuna
5) ???
* 1) 0.4.2.6-*
It doesn't seem like it, but its been over a month since the 0.4.2.6
release came out and things are still in pretty good shape. There
have been a series of pretty useful updates [1] since then, but no
real show stopper calling for a new release to get pushed. However,
in the last day or two we've had some really good bugfixes sent in
(thanks anon and Sugadude!), and if we weren't on the verge of the
0.5 release, I'd probably package 'er up and push 'er out. anon's
update fixes a border condition in the streaming lib which has been
causing many of the timeouts seen in BT and other large transfers,
so if you're feeling adventurous, grab CVS HEAD and try 'er out. Or
wait around for the next release, of course.
[1] <a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD</a>
* 2) 0.5
Lots and lots of progress on the 0.5 front (as anyone on the i2p-cvs
list [2] can attest to). All of the tunnel updates and various
performance tweaks have been tested out, and while it doesn't
include much in the way of the various [3] enforced ordering
algorithms, it does get the basics covered. We've also integrated
a set of (BSD licensed) Bloom filters [4] from XLattice [5],
allowing us to detect replay attacks without requiring any
per-message memory usage and nearly 0ms overhead. To accomodate our
needs, the filters have been trivially extended to decay so that
after a tunnel expires, the filter doesn't have the IVs we saw in
that tunnel anymore.
While I'm trying to slip in as much as I can into the 0.5 release, I
also realize that we need to expect the unexpected - meaning the
best way to improve it is to get it into your hands and learn from
how it works (and doesn't work) for you. To help with this, as I've
mentioned before, we're going to have a 0.5 release (hopefully out in
the next week), breaking backwards compatability, then work on
improving it from there, building a 0.5.1 release when its ready.
Looking back at the roadmap [6], the only thing being deferred to
0.5.1 is the strict ordering. There'll also be improvements to the
throttling and load balancing over time, I'm sure, but I expect
we'll be tweaking that pretty much forever. There have been some
other things discussed that I've hoped to include in 0.5 though,
like the download tool and the one-click update code, but it looks
like those will be deferred as well.
[2] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p-cvs/2005-February/thread.html">http://dev.i2p.net/pipermail/i2p-cvs/2005-February/thread.html</a>
[3] <a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/</a>
tunnel-alt.html?rev=HEAD#tunnel.selection.client
[4] <a rel="nofollow" href="http://en.wikipedia.org/wiki/Bloom_filter">http://en.wikipedia.org/wiki/Bloom_filter</a>
[5] <a rel="nofollow" href="http://xlattice.sourceforge.net/index.html">http://xlattice.sourceforge.net/index.html</a>
[6] <a rel="nofollow" href="http://www.i2p.net/roadmap">http://www.i2p.net/roadmap</a>
* 3) i2p-bt 0.1.6
duck has patched up a new i2p-bt release (yay!), available at the
usual locations, so get yours while its hot [7]. Between this
update and anon's streaming lib patch, I pretty much saturated my
uplink while seeding some files, so give it a shot.
[7] <a rel="nofollow" href="http://forum.i2p.net/viewtopic.php?t=300">http://forum.i2p.net/viewtopic.php?t=300</a>
* 4) fortuna
As mentioned in last week's meeting, smeghead has been churning away
at a whole slew of different updates lately, and while battling to
get I2P working with gcj, some really horrendous PRNG issues have
cropped up in some JVMs, pretty much forcing the issue of having a
PRNG we can count on. Having heard back from the GNU-Crypto folks,
while their fortuna implementation hasn't really been deployed yet,
it looks to be the best fit for our needs. We might be able to get
it into the 0.5 release, but chances are it'll get deferred to 0.5.1
though, as we'll want to tweak it so that it can provide us with the
necessary quantity of random data.
* 5) ???
Lots of things going on, and there has been a burst of activity on
the forum [8] lately as well, so I'm sure I've missed some things.
In any case, swing on by the meeting in a few minutes and say whats
on your mind (or just lurk and throw in the random snark)
=jr
[8] <a rel="nofollow" href="http://forum.i2p.net/">http://forum.i2p.net/</a>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCCSaRGnFL2th344YRApVpAKCEypMmgxmJu7ezMwKD5G3ROClh8ACfRqj6
+bDiCX8vfeua3lkyUfiF7ng=
=+m56
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/02/08/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-02-08
===============================
.. raw:: html
:file: blog/2005/02/08/status.html

89
i2p2www/blog/2005/02/15/status.html Normal file
View File

@@ -0,0 +1,89 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bonjour, sa cette fois de la semaine encore,
* Index
1) Net status
2) 0.5 status
3) i2p-bt 0.1.7
4) ???
* 1) Net status
While no new bugs have shown up in the network, last week we gained
some exposure on a popular French p2p website, which has led to an
increase both in users and in bittorrent activity. At the peak, we
reached 211 routers on the net, though its hovering between 150 and
180 lately. Reported bandwidth usage has been up as well, though
unfortunately the irc reliability has been degraded, with one of the
servers lowering their bandwidth limits due to the load. There have
been a bunch of improvements to the streaming lib to help with this,
but they've been on the 0.5-pre branch, so not yet available to the
live net.
Another transient problem has been the outage of one of the HTTP
outproxies (www1.squid.i2p), causing 50% of outproxy requests to
fail. You can temporarily remove that outproxy by opening up your
I2PTunnel config [1], editing the eepProxy, and changing the
&quot;Outproxies:&quot; line to contain only &quot;squid.i2p&quot;. Hopefully we'll
get that other one back online soon to increase redundancy.
[1] <a rel="nofollow" href="http://localhost:7657/i2ptunnel/index.jsp">http://localhost:7657/i2ptunnel/index.jsp</a>
* 2) 0.5 status
There has been lots of progress this past week on 0.5 (I bet you're
tired of hearing that, 'eh?). Thanks to the help of postman,
cervantes, duck, spaetz, and some unnamed person, we've been running
a test network with the new code for nearly a week and have worked
through a good number of bugs that I hadn't seen in my local test
network.
For the past day or so now, the changes have been minor, and I don't
forsee any substantial code left before the 0.5 release goes out.
There is some additional cleaning, documentation, and assembly left,
and it doesn't hurt to let the 0.5 test network churn through in
case additional bugs are exposed over time. Since this is going to
be a BACKWARDS INCOMPATIBLE RELEASE, to give you time to plan for
updating, I'll fix a simple deadline of THIS FRIDAY as when 0.5
will be released.
As bla mentioned on irc, eepsite hosts may want to take their site
down on Thursday or Friday and keep them down until Saturday when
many users will have upgraded. This will help reduce the effect of
an intersection attack (e.g. if 90% of the network has migrated to
0.5 and you're still on 0.4, if someone reaches your eepsite, they
know you're one of the 10% of routers left on the network).
I could start to get into whats been updated in 0.5, but I'd end up
going on for pages and pages, so perhaps I should just hold off and
put that into the documentation which I should write up :)
* 3) i2p-bt 0.1.7
duck has put together a bugfix release to last week's 0.1.6 update,
and word on the street says its kickass (perhaps /too/ kickass,
given the increased network usage ;) More info up @ the i2p-bt
forum [2]
[2] <a rel="nofollow" href="http://forum.i2p.net/viewtopic.php?t=300">http://forum.i2p.net/viewtopic.php?t=300</a>
* 4) ???
Lots of other things going on in the IRC discussions and on the
forum [3], too much to briefly summarize. Perhaps the interested
parties can swing by the meeting and give us updates and thoughts?
Anyway, see y'all shortly
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCEl/OGnFL2th344YRAkZQAKC5A+M6tX01BKKplopedAqvpV0QZQCgy+C7
Cbz/JT+3L2OfdhKAy8p/isQ=
=VUm2
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/02/15/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-02-15
===============================
.. raw:: html
:file: blog/2005/02/15/status.html

80
i2p2www/blog/2005/02/22/status.html Normal file
View File

@@ -0,0 +1,80 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, weekly update time
* Index
1) 0.5
2) Next steps
3) azneti2p
4) ???
* 1) 0.5
As y'all have heard, we finally got 0.5 out the door, and for the
most part, its been doing pretty well. I really appreciate how
quickly people have updated - within the first day, 50-75% of the
net was up to 0.5! Because of the fast adoption, we've been able
to see the impact of the various changes more quickly, and in turn
have found a bunch of bugs. While there are still some outstanding
issues, we will be putting out a new 0.5.0.1 release later this
evening to address the most important ones.
As a side benefit of the bugs, its been neat to see that routers can
handle thousands of tunnels ;)
* 2) Next steps
After the 0.5.0.1 release, there may be another build to experiment
with some changes in the exploratory tunnel building (such as using
only one or two not-failing peers, the rest being high capacity,
instead of all of the peers being not-failing). After that, we'll
be jumping towards 0.5.1, which will improve the tunnel throughput
(by batching multiple small messages into a single tunnel message)
and allow the user more control over their suceptability to the
predecessor attack.
Those controls will take the form of per-client peer ordering and
selection strategies, one for the inbound gateway and outbound
endpoint, and one for the rest of the tunnel. Current thumbnail
sketch of strategies I forsee:
= random (what we have now)
= balanced (explicitly try to reduce how often we use each peer)
= strict (if we ever use A--&gt;B--&gt;C, they stay in that order
during subsequent tunnels [bounded by time])
= loose (generate a random key for the client, calculate the XOR
from that key and each peer, and always order the peers
selected by the distance from that key [bounded by time])
= fixed (always use the same peers per MBTF)
Anyway, thats the plan, though I'm not sure which strategies will be
rolled out first. Suggestions more than welcome :)
* 3) azneti2p
The folks over at azureus have been working hard with a slew of
updates, and their latest b34 snapshot [1] seems to have some I2P
related bugfixes. While I havent had time to audit the source since
that last anonymity issue I raised, they have fixed that particular
bug, so if you're feeling adventurous, go snag their update and give
'er a try!
[1] <a rel="nofollow" href="http://azureus.sourceforge.net/index_CVS.php">http://azureus.sourceforge.net/index_CVS.php</a>
* 4) ???
Lots and lots of stuff going on, and I'm sure I haven't come close
to covering things. Swing on by the meeting in a few minutes and
see whats up!
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCG5uVGnFL2th344YRAqaGAJ9HqYx8unEZn57ZCd04mSG4hMPO1QCgsXBY
nNdoN5D/aKLL0XdusZcigTA=
=rhto
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/02/22/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-02-22
===============================
.. raw:: html
:file: blog/2005/02/22/status.html

93
i2p2www/blog/2005/03/01/status.html Normal file
View File

@@ -0,0 +1,93 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, time for our status update
* Index
1) 0.5.0.1
2) roadmap
3) addressbook editor and config
4) i2p-bt
5) ???
* 1) 0.5.0.1
As discussed last week, a few hours after the meeting we pushed out
a new 0.5.0.1 release fixing the bugs in 0.5 that had caused the
massive number of tunnels being built (among other things).
Generally, this rev has improved things, but under wider testing,
we've come across some additional bugs that have been hitting a few
people. In particular, the 0.5.0.1 rev can gobble tons of CPU if
you have a slow machine or your router's tunnels fail in bulk, and
some long lived I2PTunnel servers can gobble up RAM until it OOMs.
There has also been a long standing bug in the streaming lib, where
we can fail to establish a connection if just the right failures
happen.
Most of these (among others) have been fixed in cvs, but some remain
outstanding. Once they're all fixed, we'll package 'er up and ship
it as a 0.5.0.2 release. I'm not exactly sure when that'll be,
hopefully this week, but we'll see.
* 2) roadmap
After major releases, the roadmap [1] seems to get... adjusted. The
0.5 release was no different. That page reflects what I think is
reasonable and appropriate for the way forward, but of course, if
more people jump on to help out with things, it can certainly be
adjusted. You'll notice the substantial break between 0.6 and
0.6.1, and while this does reflect lots of work, it also reflects
the fact that I'll be moving (its that time of the year again).
[1] <a rel="nofollow" href="http://www.i2p.net/roadmap">http://www.i2p.net/roadmap</a>
* 3) addressbook editor and config
Detonate has started some work on a web based interface to manage
the addressbook entries (hosts.txt), and its looking pretty
promising. Perhaps we can get an update from detonate during the
meeting?
In addition, smeghead has been doing some work on a web based
interface to manage the addressbook configuration (the
subscriptions.txt, config.txt). Perhaps we can get an update from
smeghead during the meeting?
* 4) i2p-bt
There's been some progress on the i2p-bt front, with a new 0.1.8
release addressing the azneti2p compatability issues as discussed
in last week's meeting. Perhaps we can get an update from duck or
smeghead during the meeting?
Legion has also created a fork off the i2p-bt rev, merged in some
other code, patched up some things, and has a windows binary
available on his eepsite. The announcement [2] seems to suggest
that source may be made available, though its not up on the eepsite
at the moment. The i2p devs haven't audited (or even seen) the code
to that client, so those who need anonymity may want to get and
review a copy of the code first.
[2] <a rel="nofollow" href="http://forum.i2p.net/viewtopic.php?t=382">http://forum.i2p.net/viewtopic.php?t=382</a>
There's also work on a version 2 of Legion's BT client, though I
don't know the status of that. Perhaps we can get an update from
Legion during the meeting?
* 5) ???
Thats about all I have to say atm, lots and lots going on. Anyone
else working on things that perhaps we can get an update for during
the meeting?
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCJNebGnFL2th344YRAobNAJ4lfCULXX7WAGZxOlh/NzTuV1eNwgCg1eV/
/h5I4b/h0SPpmq/GVKZsLns=
=EEkH
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/03/01/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-03-01
===============================
.. raw:: html
:file: blog/2005/03/01/status.html

69
i2p2www/blog/2005/03/08/status.html Normal file
View File

@@ -0,0 +1,69 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, weekly update time
* Index
1) 0.5.0.2
2) mail.i2p updates
3) i2p-bt updates
4) ???
* 1) 0.5.0.2
The other day we pushed out the 0.5.0.2 release and a good portion
of the network has upgraded (yay!) Reports are coming in that the
worst offenders from 0.5.0.1 have been killed, and overall things
seem to be working fine. There are still some reliability issues,
though the streaming lib has been handling it (irc connections
lasting for 12-24+ hours seems the norm). I've been trying to
track down some of the issues remaining, but it would be really,
really good if everyone got up to date ASAP.
As things stand for moving forward, reliability is king. Only after
an overwhelming majority of messages that should succeed do succeed
will there be work on improving throughput. Beyond the batching
tunnel preprocessor, another dimension we may want to explore is
feeding more latency data into the profiles. We currently only use
test and tunnel management messages to determine each peer's &quot;speed&quot;
ranking, but we should probably snag any measurable RTTs for other
actions, such as netDb and even end to end client messages. On the
other hand, we'll have to weight them accordingly, since for an
end to end message, we cannot separate the four portions of the
measurable RTT (our outbound, their inbound, their outbound, our
inbound). Perhaps we can do some garlic trickery to bundle a
message targetting one of our inbound tunnels along side some
outbound messages, cutting the other side's tunnels out of the
measurement loop.
* 2) mail.i2p updates
Ok, I don't know what updates postman has in store for us, but
there'll be an update during the meeting. See the logs to find
out!
* 3) i2p-bt update
I don't know what updates duck &amp; gang have for us, but I've heard
some ruminations of progress on the channel. Perhaps we can get
an update out of 'im.
* 4) ???
Lots and lots going on, but if there's anything in particular y'all
want to bring up and discuss, swing on by the meeting in a few
minutes. Oh, and just a reminder, if you haven't upgraded yet,
please do so ASAP (upgrading is insanely simple - download a file,
click a button)
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCLgzVGnFL2th344YRAuY0AKCg03zFJBDbWYjV4jqd96gKtBhpFwCgwLLP
EHsY9W9LztKK3FZBHPN2FyE=
=QUzy
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/03/08/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-03-08
===============================
.. raw:: html
:file: blog/2005/03/08/status.html

70
i2p2www/blog/2005/03/15/status.html Normal file
View File

@@ -0,0 +1,70 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, weekly update time
* Index
1) Net status
2) Feedspace
3) ???
* 1) Net status
Over the last week, much of my time has been spent analyzing the
network's behavior, tracking stats and trying to reproduce various
events in the simulator. While some of the funky network behavior
can be attributed to the two dozen or so routers still on older
versions, the key factor is that our speed calculations aren't
giving us good data - we aren't able to properly identify peers who
can pump data quickly. In the past, this wasn't much of a problem,
since there was a bug causing us to use the 8 highest capacity peers
as the 'fast' pool, rather than building legitimate capacity derived
tiers. Our current speed calculation is derived from a periodic
latency test (the RTT of a tunnel test, in particular), but that
provides insufficient data to have any confidence in the value.
What we need is a better way to gather more data points while still
allowing 'high capacity' peers to be promoted to the 'fast' tier, as
necessary.
To verify that this is the key problem we're facing, I cheated a bit
and added functionality to manually select what peers should be used
in a particular tunnel pool's selection. With those explicitly
chosen peers, I've had over two days on irc without disconnect and
fairly reasonable performance w/ another service I control. For the
last two days or so, I've been trying out a new speed calculator
using some new stats, and while it has improved selection, it still
has some problems. I've worked through a few alternatives this
afternoon, but there's still work to be done to try 'em out on the
net.
* 2) Feedspace
Frosk has put up another rev of the i2pcontent/fusenet docs, except
now at a new home with a new name: <a rel="nofollow" href="http://feedspace.i2p/">http://feedspace.i2p/</a> - see
either orion [1] or my blog [2] for the destination. This stuff
looks really promising, both from the perspective of &quot;hey, kickass
functionality&quot; and &quot;hey, that'll help I2P's anonymity&quot;. Frosk and
gang are working away, but they're most certainly looking for input
(and help). Perhaps we can get Frosk to give us an update in the
meeting?
[1] <a rel="nofollow" href="http://orion.i2p/#feedspace.i2p">http://orion.i2p/#feedspace.i2p</a>
[2] <a rel="nofollow" href="http://jrandom.dev.i2p/">http://jrandom.dev.i2p/</a>
* 3) ???
Ok, it may not look like much, but there's lots going on, really :)
I'm sure I've missed some things too, so swing on by the meeting
and see whats up.
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCN0wvGnFL2th344YRAvQbAKDT3rvYHcqAwuFyNEjW4WhRWgjucwCg4Z4S
mvxKNX+jQ7jnfBFyJponyCc=
=NMuv
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/03/15/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-03-15
===============================
.. raw:: html
:file: blog/2005/03/15/status.html

83
i2p2www/blog/2005/03/22/status.html Normal file
View File

@@ -0,0 +1,83 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, quick status update
* Index
1) 0.5.0.3
2) batching
3) updating
4) ???
* 0.5.0.3
The new release is out and about, and most of y'all have upgraded
fairly quickly - thanks! There were some bugfixes to various
issues, but nothing revolutionary - the biggest part was dropping
0.5 and 0.5.0.1 users off the net. I've been tracking the net's
behavior since then, digging through what's going on, and while
there has been some improvement, there are still some things that
need to get sorted out.
There'll be a new release in the next day or two with a bugfix for
an issue that no one has run into yet, but that breaks the new
batching code. There will also be some tools for automating the
update process according to the user's preferences, along with other
minor things.
* batching
As I mentioned in my blog, there's room for dramatically reducing
the bandwidth and message count required on the net by doing some
very simple batching of tunnel messages - rather than putting each
I2NP message, regardless of size, in a tunnel message of its own,
by adding in a brief delay we can bundle up to 15 or more within
a single tunnel message. The biggest gains there will occur with
services that use small messages (such as IRC), while large file
transfers will not be affected by this much. The code to perform
the batching has been implemented and tested, but unfortunately
there's a bug on the live net which would cause all but the first
I2NP message within a tunnel message to be lost. Thats why we're
going to have an interim release with that fix in it, followed by
the batching release a week or so after that.
* updating
In this interim release, we're going to be shipping some of the
oft discussed 'autoupdate' code. We've got the tools to
periodically check for authentic update announcements, download
the update either anonymously or not, and then either install it
or simply display a notice on the router console telling you that
its ready and waiting for installation. The update itself will
now use smeghead's new signed update format which is essentially
the update plus a DSA signature. The keys used to verify that
signature will be bundled with I2P, as well as configurable on
the router console.
The default behavior will be to simply periodically check for update
announcements but not to act on them - just to display a one-click
&quot;Update now&quot; feature on the router console. There will be lots of
other scenarios for different user needs, but they'll hopefully all
be accounted for through a new configuration page.
* ???
I'm feeling a bit under the weather, so the above doesn't really go
into all the detail about whats up. Swing on by the meeting and
fill in the gaps :)
Oh, as an aside, I'll be pushing out a new PGP key for myself in the
next day or two as well (since this one expires shortly...), so keep
an eye out.
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCQIW+GnFL2th344YRAj03AKCAwDNl6Dr/4Xi6l9x4kOhw8YIkEwCglfFc
98JQv3aXNdaBiA65c5DP8c8=
=qfoJ
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/03/22/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-03-22
===============================
.. raw:: html
:file: blog/2005/03/22/status.html

87
i2p2www/blog/2005/03/29/status.html Normal file
View File

@@ -0,0 +1,87 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, time for the weekly status notes
* Index
1) 0.5.0.5
2) UDP (SSU)
3) Q
4) ???
* 1) 0.5.0.5
Since y'all did such a great job at upgrading to 0.5.0.4 so quickly,
we're going to have the new 0.5.0.5 release come out after the
meeting. As discussed last week, the big change is the inclusion of
the batching code, bundling multiple small messages together, rather
than giving them each their own full 1KB tunnel message. While this
alone won't be revolutionary, it should substantially reduce the
number of messages passed, as well as the bandwidth used, especially
for services like IRC.
There will be more info in the release announcement, but two other
important things come up with the 0.5.0.5 rev. First, we're
dropping support for users before 0.5.0.4 - there are well over 100
users on 0.5.0.4, and there are substantial problems with earlier
releases. Second, there's an important anonymity fix in the new
build, that while it'd require some development effort to mount, its
not implausible. The bulk of the change is to how we manage the
netDb - rather than play it fast and loose and cache entries all
over the place, we will only respond to netDb requests for elements
that have been explicitly given to us, regardless of whether or not
we have the data in question.
As always, there are bugfixes and some new features, but more info
will be forthcoming in the release announcement.
* 2) UDP (SSU)
As discussed off and on for the last 6-12 months, we're going to be
moving over to UDP for our interrouter communication once the 0.6
release is out. To get us further down that path, we've got a first
draft of the transport protocol up in CVS @
<a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html?rev=HEAD">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html?rev=HEAD</a>
Its a fairly simple protocol with the goals outlined in the doc, and
exploits I2P's capabilities to both authenticate and secure data, as
well as expose as little external information as possible. Not even
the first part of a connection handshake is identifiable to someone
that isn't running I2P. The behavior of the protocol is not fully
defined in the spec yet, such as how the timers fire or how the three
different semireliable status indicators are used, but it does cover
the basics of the encryption, packetization, and NAT hole punching.
None of it has been implemented yet, but will be soon, so feedback
would be greatly appreciated!
* 3) Q
Aum has been churning away on Q(uartermaster), a distributed store,
and the first pass of the docs are up [1]. One of the interesting
ideas in there seems to be a move away from a straight DHT towards
a memcached [2] style system, with each user doing any searches
entirely *locally*, and requesting the actual data from the Q server
&quot;directly&quot; (well, through I2P). Anyway, some neat stuff, perhaps
if Aum is awake [3] we can wressle an update out of him?
[1] <a rel="nofollow" href="http://aum.i2p/q/">http://aum.i2p/q/</a>
[2] <a rel="nofollow" href="http://www.danga.com/memcached/">http://www.danga.com/memcached/</a>
[3] damn those timezones!
* 4) ???
Lots more going on, and if there were more than just a few minutes
until the meeting I could go on, but c'est la vie. Swing on by
#i2p in a few to chat.
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCSbNjWYfZ3rPnHH0RAi5qAKCNE+jorT/F1QPif4a1EPaTKg1DwwCggVy9
Kk+3I6WgqDjqaNKSc5xnoQA=
=iXNV
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/03/29/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-03-29
===============================
.. raw:: html
:file: blog/2005/03/29/status.html

56
i2p2www/blog/2005/04/05/status.html Normal file
View File

@@ -0,0 +1,56 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, time for the weekly update
* Index
1) 0.5.0.5
2) Bayesian peer profiling
3) Q
4) ???
* 1) 0.5.0.5
Last week's 0.5.0.5 release has had its ups and downs - the major
change to address some attacks in the netDb seems to work as
expected, but has exposed some long overlooked bugs in the netDb's
operation. This has caused some substantial reliability issues,
especially for eepsites. The bugs have however been identified and
addressed in CVS, and those fixes among a few others will be pushed
out as a 0.5.0.6 release within the next day.
* 2) Bayesian peer profiling
bla has been doing some research into improving our peer profiling
by exploiting simple bayesian filtering from the gathered stats [1].
It looks quite promising, though I'm not sure where it stands at the
moment - perhaps we can get an update from bla during the meeting?
[1] <a rel="nofollow" href="http://forum.i2p.net/viewtopic.php?t=598">http://forum.i2p.net/viewtopic.php?t=598</a>
<a rel="nofollow" href="http://theland.i2p/nodemon.html">http://theland.i2p/nodemon.html</a>
* 3) Q
There is lots of progress going on with aum's Q app, both in the
core functionality and with a few people building various xmlrpc
frontends. Rumor has it we might be seeing another Q build out this
weekend with a whole slew of goodies described on <a rel="nofollow" href="http://aum.i2p/q/">http://aum.i2p/q/</a>
* 4) ???
Ok, yeah, very brief status notes, as I got the timezones mixed up
*again* (actually, I got the days mixed up too, thought it was
Monday until a few hours ago). Anyway, there is lots of stuff going
on not mentioned above, so swing on by the meeting and see whats up!
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCUvNtWYfZ3rPnHH0RAlzmAKCAX5PQP8s2wWIxhWnHWG6eeps1nQCffkNC
Li2s44HU5EehnMoCMxIOZlc=
=WNZp
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/04/05/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-04-05
===============================
.. raw:: html
:file: blog/2005/04/05/status.html

126
i2p2www/blog/2005/04/12/status.html Normal file
View File

@@ -0,0 +1,126 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, update time again
* Index
1) Net status
2) SSU status
3) Bayesian peer profiling
4) Q status
5) ???
* 1) Net status
Last week's 0.5.0.6 release seems to have fixed the netDb issues we
were seeing (yay). Sites and services are much more reliable than
they were on 0.5.0.5, though there have been some reports of trouble
where a site or service would become unreachable after a few days
uptime.
* 2) SSU status
There's been lots of progress on the 0.6 UDP code, with the first
batch of commits already made to CVS. Its not anything you could
actually use yet, but the fundamentals are in place. Session
negotiation works well and the semireliable message delivery
performs as expected. There's still a lot of work to do though,
test cases to write, and oddball situations to debug, but its
progress.
If things go well, we may have some alpha testing next week, just
for people who can explicitly configure their firewalls/NATs. I'd
like to get the general operation hammered out first before adding
in the relay handler, tuning up the netDb for faster routerInfo
expiration, and selecting relays to publish. I'm also going to take
this opportunity to do a whole slew of testing, as there are several
critical queueing factors being addressed.
* 3) Bayesian peer profiling
bla has been churning away at some revisions to how we decide what
peers to tunnel through, and though bla couldn't make it to the
meeting, there's some interesting data to report:
&lt;+bla&gt; I've performed direct node speed measurements: I've profiled
some 150 nodes by using OB tunnels of length 0, IB tunnels of
length 1, batching-interval = 0ms
&lt;+bla&gt; In addition, I've just done some _very_ basic and
_preliminary_ speed estimation using naive Bayesian
classification
&lt;+bla&gt; The latter was done using the default expl. tunnel lengths
&lt;+bla&gt; The intersection between the set of nodes on which I have
&quot;ground truth&quot;, and the set of nodes in the current
measurements, is 117 nodes
&lt;+bla&gt; Results are not _that_ bad, but not too impressive either
&lt;+bla&gt; See <a rel="nofollow" href="http://theland.i2p/estspeed.png">http://theland.i2p/estspeed.png</a>
&lt;+bla&gt; Basic very-slow/fast separation is ok-ish, but fine-grained
separation among the faster peers could be much better
&lt;+jrandom2p&gt; hmm, how'd the actual values get calculated - is that
full RTT or is it RTT/length ?
&lt;+bla&gt; Using the normal expl. tunnels, it's next to impossible to
prevent batching delays.
&lt;+bla&gt; The actual values are the ground-truth values: those obtained
using OB=0 and IB=1
&lt;+bla&gt; (and variance=0, and no batching delay)
&lt;+jrandom2p&gt; the results look pretty good from here though
&lt;+bla&gt; The estimated timings are those obtained using Bayesian
inference from _actual_ expl. tunnels of length 2 +/- 1
&lt;+bla&gt; This is obtained from 3000 RTTs, recorded over a period of
about 3 hours (that's long)
&lt;+bla&gt; It does assume (for the moment) that peer speed is static.
I've yet to implement weighting
&lt;+jrandom2p&gt; sounds kickass. nice work bla
&lt;+jrandom2p&gt; hmm, so the estimate should equal 1/4 actual
&lt;+bla&gt; jrandom: No: All measured RTTs (using the normal expl.
tunnels), are corrected for the number of hops in the
round-trip
&lt;+jrandom2p&gt; ah ok
&lt;+bla&gt; Only after that, the Bayesian classifier is trained
&lt;+bla&gt; For now, I bin the measured times-per-hop into 10 classes:
50, 100, ..., 450 ms, and an additional class &gt;500 ms
&lt;+bla&gt; E.g., small delays-per-hop could be weighted using a larger
factor, as could complete failures (&gt;60000 ms).
&lt;+bla&gt; Though.... 65% of the estimated timings, fall within 0.5
standard deviations from the actual node time
&lt;+bla&gt; However, this has to be redone, since the standard deviation
is influenced heavily by the &gt;60000 ms failures
After further discussion, bla pulled up a comparison against the
existing speed calculator, posted @ <a rel="nofollow" href="http://theland.i2p/oldspeed.png">http://theland.i2p/oldspeed.png</a>
Mirrors of those pngs are up at
<a rel="nofollow" href="http://dev.i2p.net/~jrandom/estspeed.png">http://dev.i2p.net/~jrandom/estspeed.png</a> and
<a rel="nofollow" href="http://dev.i2p.net/~jrandom/oldspeed.png">http://dev.i2p.net/~jrandom/oldspeed.png</a>
(for terminology, IB=inbound tunnel hops, OB=outbound tunnel hops,
and after some clarification, the &quot;ground truth&quot; measurements were
obtained by 1 hop outbound and 0 hop inbound, not the other way
around)
* 4) Q status
Aum has been making lots of headway on Q as well, most recently
working on a web based client interface. The next Q build will not
be backwards compatible, as it includes a whole slew of new
features, but I'm sure we'll hear more info from Aum when there's
more info to be heard :)
* 5) ???
Thats about it for the moment (gotta wrap this up before meeting
time). Oh, as an aside, it looks like I'll be moving earlier than
planned, so perhaps some of the dates in the roadmap might shift
around while I'm in transit to wherever I end up. Anyway, swing
on by the channel in a few minutes to harass us with new ideas!
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCXCZwWYfZ3rPnHH0RAkFGAJwPHpB7/VkZjOtpLNojf+210p0CeACfeC7t
ONGe96zS1hmVNeAzqQgjeUo=
=0FjK
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/04/12/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-04-12
===============================
.. raw:: html
:file: blog/2005/04/12/status.html

79
i2p2www/blog/2005/04/19/status.html Normal file
View File

@@ -0,0 +1,79 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, its that time of the week again,
* Index
1) Net status
2) SSU status
3) Roadmap update
4) Q status
5) ???
* 1) Net status
Over the nearly two weeks since 0.5.0.6 came out, things have been
mostly positive, though service providers (eepsites, ircd, etc) have
been running into some bugs as of late. While clients are in good
shape, over time a server may run into situation where failing
tunnels can trigger some excessive throttling code, preventing
proper rebuilding and publication of the leaseSet.
There have been some fixes in CVS, among other things, and I expect
that we'll have a new 0.5.0.7 out in the next day or so.
* 2) SSU status
For those not following my (oh so exciting) blog, there's been a lot
of progress with the UDP transport, and right now its fairly safe to
say that the UDP transport will not be our throughput bottleneck :)
While debugging that code, I've taken the opportunity to work
through the queueing at higher levels as well, finding points where
we can remove unnecessary choke points. As I said last week,
though, there's still a lot of work to do. More info will be
available when there's more info available.
* 3) Roadmap update
Its april now, so the roadmap [1] has been updated accordingly -
dropping 0.5.1 and shifting some dates. The big change there is
moving 0.6 from April to June, though that really isn't as big of a
change as it looks like. As I mentioned last week, my own schedule
has moved around a bit, and rather than moving to $somewhere in
June, I'm moving to $somewhere in May. While we could have whats
necessary for 0.6 ready this month, there is no way I'm going to
shove out a major update like that and then dissapear for a month,
since the reality of software is that there'll be bugs not caught
in testing.
[1] <a rel="nofollow" href="http://www.i2p.net/roadmap">http://www.i2p.net/roadmap</a>
* 4) Q status
Aum has been going wild on Q, putting in more goodies for us, with
the latest screenshots up on his site [2]. He has also committed
the code to CVS too (yay), so we'll hopefully be able to begin alpha
testing soon. I'm sure we'll hear more from aum with details on how
to help, or you can dig into the goods in CVS at i2p/apps/q/
[2] <a rel="nofollow" href="http://aum.i2p/q/">http://aum.i2p/q/</a>
* 5) ???
There has been lots more going on as well, with some lively
discussions on the mailing list, the forum, and irc. I'm not
going to try to summarize those here, since there are only a few
minutes until the meeting, but swing on by if there's something not
discussed that you want to bring up!
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCZWKUWYfZ3rPnHH0RArKcAJ0dGCGnQhNu7dvncvPRdOqYe3Q5MQCfcz9X
T3H2xh74GXTtBdOloaAHS9o=
=iRwf
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/04/19/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-04-19
===============================
.. raw:: html
:file: blog/2005/04/19/status.html

60
i2p2www/blog/2005/04/26/status.html Normal file
View File

@@ -0,0 +1,60 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, brief weekly status notes today
* Index
1) Net status
2) SSU status
3) Unit test bounty
4) ???
* 1) Net status
Most people have upgraded to last weeks 0.5.0.7 release fairly
quickly (thanks!) and the overall result seems positive. The net
seems fairly reliable and the previous tunnel throttling has been
resolved. There are still some intermittent problems reported by
some users though, and we're tracking those down.
* 2) SSU status
Most of my time is spent focused on the 0.6 UDP code, and no, its
not ready for release, and yes, there is progress ;) Right now it
can handle multiple networks, keeping some peers on UDP and others
on TCP with fairly reasonable performance. The hard part is working
through all the congestion/contention cases, since the live net will
be under constant load, but there's been a lot of progress there in
the last day or so. More news when there's more news.
* 3) Unit test bounty
As duck mentioned on the list [1], zab has seeded a bounty to help
out I2P with a series of testing updates - some funds for anyone who
can complete the tasks listed on the bounty page [2]. We've had
some further donations to that bounty [3] - it currently stands at
$1000USD. While the bounties certainly don't offer &quot;market rate&quot;,
they are a small token of encouragement for developers who want to
help out.
[1] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p/2005-April/000721.html">http://dev.i2p.net/pipermail/i2p/2005-April/000721.html</a>
[2] <a rel="nofollow" href="http://www.i2p.net/bounty_unittests">http://www.i2p.net/bounty_unittests</a>
[3] <a rel="nofollow" href="http://www.i2p.net/halloffame">http://www.i2p.net/halloffame</a>
* 4) ???
Ok, I'm late for the meeting again... I should probably sign and
send this out, 'eh? Swing on by the meeting and we can discuss
other issues as well.
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCbp6hWYfZ3rPnHH0RAk5YAJ9hkbwuzcBwR2rKRSfRZFsjP3q2zACeNz+/
VBGnM3PHevpd6dpqHoI/tvg=
=aMPe
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/04/26/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-04-26
===============================
.. raw:: html
:file: blog/2005/04/26/status.html

106
i2p2www/blog/2005/05/03/status.html Normal file
View File

@@ -0,0 +1,106 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, lots of stuff on the table this week
* Index
1) Net status
2) SSU status
3) i2phex
4) awol
5) ???
* 1) Net status
No big changes on the overall network health - things seem fairly
stable, and though we've got the occational bump services seem to be
doing well. There have been lots of updates to CVS since the last
release but no show stopper bug fixes. We may have one more release
before my move, just to get the latest CVS out further, but I'm not
sure yet.
* 2) SSU status
Are you tired of hearing me say that there's been lots of progress
on the UDP transport? Well, too bad - there's been lots of progress
on the UDP transport. Over the weekend we moved off the private
network testing and onto the live net and a dozen or so routers
upgraded and exposed their SSU address - allowing them to be
reachable by the TCP transport by most users but letting SSU enabled
routers to talk via UDP.
The testing still very early, but it went much better than I
expected. Congestion control was very well behaved and both
throughput and latency were quite sufficient - it was able to
properly identify real bandwidth limits and effectively share that
link with competing TCP streams.
With the stats gathered from the helpful volunteers, it became clear
how important the selective acknowledgement code is to proper
operation in highly congested networks. I've spent the last few
days implementing and testing that code, and have updated the SSU
spec [1] to include a new efficient SACK technique. It won't be
backwards compatible with the earlier SSU code, so people who have
been helping test should disable the SSU transport until a new build
is ready for testing (hopefully in the next day or two).
[1]<a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html?rev=HEAD">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html?rev=HEAD</a>
* 3) i2phex
sirup has been churning away on a port of phex to i2p, and while
there's a lot of work to do before its ready for joe sixpack,
earlier this evening I was able to fire it up, browse sirup's shared
files, grab some data, and use its *cough* &quot;instant&quot; chat interface.
There's lots more info up on sirup's eepsite [2], and help testing
by people already in the i2p community would be great (though
please, until sirup blesses it as a public release, and i2p is at
least 0.6 if not 1.0, lets keep it within the i2p community). I
believe sirup will be around for this week's meeting, so perhaps we
can get some more info then!
[2]<a rel="nofollow" href="http://sirup.i2p/">http://sirup.i2p/</a>
* 4) awol
Speaking of being around, I probably won't be here for next week's
meeting and will be offline for the following 3-4 weeks. While that
probably means there won't be any new releases, there are still a
bunch of really interesting things for people to hack on:
= applications like feedspace, i2p-bt/ducktorrent, i2phex, fire2pe,
the addressbook, susimail, q, or something completely new.
= the eepproxy - it'd be great to get filtering, support for
persistent HTTP connections, 'listen on' ACLs, and perhaps an
exponential backoff to deal with outproxy timeouts (rather than
plain round robin)
= the PRNG (as discussed on the list)
= a PMTU library (either in Java or in C with JNI)
= the unit test bounty and the GCJ bounty
= router memory profiling and tuning
= and a whole lot more.
So, if you're feeling bored and want to help out, but are in need of
inspiration, perhaps one of the above might get you going. I'll
probably stop by a net cafe every once in a while, so I'll be
reachable through email, but the response time will be O(days).
* 5) ???
Ok, thats about all I've got to bring up for the moment. For those
who want to help out with the SSU testing over the next week, keep
an eye out for info on my blog [3]. For the rest of y'all, I'll see
you at the meeting!
=jr
[3]<a rel="nofollow" href="http://jrandom.dev.i2p/">http://jrandom.dev.i2p/</a>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCd81nWYfZ3rPnHH0RAuoTAJ0VhtNJjYB7sv0XecoCCBvz63z/GACfasKz
vJ2B+nJiHEMLwobhZIRS2hQ=
=E3vU
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/05/03/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-05-03
===============================
.. raw:: html
:file: blog/2005/05/03/status.html

113
i2p2www/blog/2005/06/21/status.html Normal file
View File

@@ -0,0 +1,113 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, time to start back up our weekly status notes
* Index
1) Dev[eloper] status
2) Dev[elopment] status
3) Unit test bounty
4) Service outage
5) ???
* 1) Dev[eloper] status
After 4 cities in 4 countries, I'm finally getting settled and
churning through code again. Last week I got the last of the
pieces to a laptop together, I'm no longer couch hopping, and
while I don't have net access at home, there are plenty of net
cafes around, so access is reliable (just infrequent and
expensive).
That last point means that I won't be hanging out on irc as much
as before, at least until the fall (I've got a sublet through
August or so and will be looking for a place where I can get 24/7 net
access). That doesn't, however, mean that I won't be doing as
much - I'll just be working largely on my own test network, pushing
out builds for live net testing (and, er, oh yeah, releases). It
does mean though that we may want to move some discussions that used
to go on free form in #i2p onto the list [1] and/or the forum [2] (I
do still read the #i2p backlog though). I haven't found a
reasonable place where I can go to for our development meetings yet,
so I won't be there this week, but perhaps by next week I'll have
found one.
Anyway, enough about me.
[1] <a rel="nofollow" href="http://dev.i2p.net/pipermail/i2p/">http://dev.i2p.net/pipermail/i2p/</a>
[2] <a rel="nofollow" href="http://forum.i2p.net/">http://forum.i2p.net/</a>
* 2) Dev[elopment] status
While I've been moving, there have been two main fronts that I've
been working on - documentation and the SSU transport (the later
only since I got the laptop). The docs are still in progress, with
a big ol' scary overview one as well as a series of smaller
implementation docs (covering things like source layout, component
interaction, etc).
SSU progress is going well - the new ACK bitfields are in place, the
communication is dealing with (simulated) loss effectively, rates
are appropriate for the various conditions, and I've cleared some of
the uglier bugs I had run into previously. I am continuing to test
these changes though, and once its appropriate we'll plot out a
series of live net tests for which we'll need some volunteers to
help out with. More news on that front when its available.
* 3) Unit test bounty
I'm glad to announce that Comwiz has come forward with a series of
patches to claim the first phase of the unit test bounty [3]! We are
still working through some minor details of the patches, but I've
received the updates and generated both the junit and clover reports
as necessary. I expect we'll have the patches in CVS shortly, at
which point we'll put out Comwiz's testing docs.
As clover is a commercial product (free for OSS developers [4]),
only those who have installed clover and received their clover
license will be able to generate the clover reports. In any case,
we'll be publishing the clover reports on the web periodically, so
those who don't have clover installed can still see how well our
test suite is doing.
[3] <a rel="nofollow" href="http://www.i2p.net/bounties_unittest">http://www.i2p.net/bounties_unittest</a>
[4] <a rel="nofollow" href="http://www.cenqua.com/clover/">http://www.cenqua.com/clover/</a>
* 4) Service outage
As many have probably noticed, (at least) one of the outproxies is
offline (squid.i2p), as is www.i2p, dev.i2p, cvs.i2p, and my blog.
These are not unrelated events - the machine hosting them is hosed.
I'm working on getting it back up though, at which point those five
services will be back in operation. Just an FYI.
* 5) ???
As there isn't a dev meeting on irc this week, if anyone else has
anything to bring up, please feel free to post up to the list or the
forum. I've been following the discussions on the list, the forum,
and in #i2p while I've been away, and have been glad to be able to
sit back and let other people answer most of the questions.
I do appreciate the patience people have had with the slow down in
releases as well, and realize that in some projects that would be
cause for alarm. I2P is not, however, one of those projects - I've
been working on it fulltime for more than two years now and will not
stop until the needs that have been driving it are met. I am not
wed to particular technologies for technologies sake, but merely
follow what seems to be the best path from here to where we need to
be, and as far as I can tell, we are still following the best path
available. This summer, fall, and winter look to be a very exciting
time in the anonymity field.
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCuEcEWYfZ3rPnHH0RAvltAJ0fuhd/QRRqICtnqITeljKRw8cbbACeInKx
gaRYTsDAU3zHBCxr4TiSl18=
=uXj9
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/06/21/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-06-21
===============================
.. raw:: html
:file: blog/2005/06/21/status.html

128
i2p2www/blog/2005/06/28/status.html Normal file
View File

@@ -0,0 +1,128 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, weekly update time again
* Index
1) SSU status
2) Unit test status
3) Kaffe status
4) ???
* 1) SSU status
There has been some more progress on the SSU transport, and my
current thinking will be that after some more live net testing,
we'll be able to deploy as 0.6 without much delay. The first
SSU release will not include support for people who cannot poke a
hole in their firewall or adjust their NAT, but that will be rolled
out in 0.6.1. After 0.6.1 is out, tested, and kicking ass (aka
0.6.1.42), we'll move on over to 1.0.
My personal leaning is towards dropping the TCP transport completely
as the SSU transport rolls out so that people won't need to have
both enabled (forwarding both TCP and UDP ports) and so that the
coders won't need to maintain code that isn't necessary. Anyone
have any strong feelings on this?
* 2) Unit test status
As mentioned last week, Comwiz has come forward to claim the first
phase of the unit test bounty (yay Comwiz! thanks duck &amp; zab for
funding the bounty too!). The code has been committed to CVS and,
depending on your local setup, you may be able to generate the junit
and clover reports by going into the i2p/core/java directory and
running &quot;ant test junit.report&quot; (wait about an hour...) and view
i2p/reports/core/html/junit/index.html. On the other hand, you can
run &quot;ant useclover test junit.report clover.report&quot; and view
i2p/reports/core/html/clover/index.html.
The downside to both sets of tests has to do with that foolish
concept the ruling class calls &quot;copyright law&quot;. Clover is a
commercial product, though the folks over at cenqua allow its free
use by open source developers (and they have kindly agreed to grant
us a license). To generate the clover reports, you need to have
clover installed locally - I have clover.jar in ~/.ant/lib/, next to
my license file. Most people won't need clover, and since we'll be
publishing the reports on the web, there is no loss of functionality
by not installing it.
On the other hand, we're being bit by the other side of copyright
law when we take into consideration the unit test framework itself -
junit is released under the IBM Common Public License 1.0, which,
according to the FSF [1], is not GPL compatible. Now, while we
don't have any GPL code ourselves (at least not in the core or the
router), looking back at our license policy [2], our aim in the
particulars of how we license things is to allow as many people as
possible to use what is being created, since anonymity loves
company.
[1]<a rel="nofollow" href="http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses">http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses</a>
[2]<a rel="nofollow" href="http://www.i2p.net/licenses">http://www.i2p.net/licenses</a>
Since some people inexplicably release software under the GPL, it
makes sense for us to strive to allow them to use I2P without
constraint. At the very least, that means we can't allow the
actual functionality we expose to be dependent upon the CPL'ed
code (e.g. junit.framework.*). I'd like to extend that to include
the unit tests as well, but junit seems to be the lingua franca of
testing frameworks (and I don't think it'd be anywhere near sane to
say &quot;hey, lets build our own public domain unit test framework!&quot;,
given our resources).
Given all that, here's what I'm thinking. We'll bundle junit.jar in
CVS and use it when people run the unit tests, but the unit tests
themselves will not be built into i2p.jar or router.jar, and will
not be pushed out in releases. We may expose an additional set of
jars (i2p-test.jar and router-test.jar), if necessary, but those
would not be usable by GPL'ed applications (since they depend upon
junit).
Any thoughts on that? (How are GPL'ed apps using junit? Simply
ignoring the FSF's view that the licenses are incompatible?)
* 3) Kaffe status
Yesterday while doing some SSU testing I decided to fire up a kaffe
instance and kick the tires a bit. The results were promising, but
there's going to be work ahead of us - their UDP code has some minor
threading issues [3], and their java lib breaks xerces [4], which we
use for jetty [5]. As there are no xerces-specific dependencies,
we just need to snag another kaffe compatible xml engine -
Dalibor [6] has suggested either GNU JAXP [7] or saxon [8]. While
GNU JAXP has been merged into GNU/Classpath, its also still
available separately under GPL + linking exception (which is fine
for us), so it looks like a promising replacement for xerces.jar.
Anyone want to look into testing that out on a few JVMs and OSes
while I continue hacking on SSU, with the aim of getting the
router console working with kaffe + GNU JAXP - xerces.jar?
[3] <a rel="nofollow" href="http://www.kaffe.org/pipermail/kaffe/2005-June/102799.html">http://www.kaffe.org/pipermail/kaffe/2005-June/102799.html</a>
[4] <a rel="nofollow" href="http://xml.apache.org/#xerces">http://xml.apache.org/#xerces</a>
[5] <a rel="nofollow" href="http://jetty.mortbay.org/">http://jetty.mortbay.org/</a>
[6] <a rel="nofollow" href="http://www.advogato.org/person/robilad/">http://www.advogato.org/person/robilad/</a>
[7] <a rel="nofollow" href="http://gnu.org/software/classpathx/jaxp/jaxp.html">http://gnu.org/software/classpathx/jaxp/jaxp.html</a>
[8] <a rel="nofollow" href="http://saxon.sourceforge.net/">http://saxon.sourceforge.net/</a>
[9] [10]
[10] just trying to increase my footnote quota
* 4) ???
Lots going on, and I'll keep y'all updated as more news becomes
available. I still havent found a good late night net cafe, so
won't be around for a meeting tonight, but, as always, if anyone
has anything to bring up, feel free to post on the list or the
forum.
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCwZh0WYfZ3rPnHH0RAjFLAJ9wy5baVmZWYbOD37AjicFd0kVPPQCfYHVb
mbSQS7iBWcts4GQpGLBmcSg=
=w/V+
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/06/28/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-06-28
===============================
.. raw:: html
:file: blog/2005/06/28/status.html

106
i2p2www/blog/2005/07/05/status.html Normal file
View File

@@ -0,0 +1,106 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi gang, its that time of the week,
* Index
1) Dev status
2) Tunnel IVs
3) SSU MACs
3) ???
* 1) Dev status
Another week, another message saying &quot;There's been a lot of progress
on the SSU transport&quot; ;) My local mods are stable and have been
pushed to CVS (HEAD sits at 0.5.0.7-9), but no release yet. More
news on that front soon. Details on the non-SSU related changes up
in the history [1], though I'm keeping SSU related changes out of
that list so far, since SSU isn't used by any non-devs yet (and devs
read i2p-cvs@ :)
[1] <a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD</a>
* 2) Tunnel IVs
For the last few days, dvorak has been posting occational thoughts
on different ways to attack the tunnel crypto, and while most of
them were already addressed, we were able to come up with one
scenario that would allow participants to tag a pair of messages to
determine that they're in the same tunnel. The way it worked was
the earlier peer would let a message go past it and then later on
swap the IV and first data block from that first tunnel message and
place it in a new one. This new one would of course be corrupt, but
it wouldn't look like a replay, since the IVs were different. Down
the line, the second peer could then just discard that message so
that the tunnel endpoint couldn't detect the attack.
One of the core issues behind it is that there are no ways to verify
a tunnel message as goes down the tunnel without opening up a whole
slew of attacks (see an earlier tunnel crypto proposal [2] for one
method that gets close, but has pretty sketchy probabilities and
imposes some artificial limits on the tunnels).
[2]<a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel.html?rev=HEAD">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel.html?rev=HEAD</a>
There is, however, a trivial way around the particular attack
outlined - simply treat xor(IV, first data block) as the unique
identifier fed through the bloom filter instead of the IV alone.
This way, intermediate peers will see the dup and drop it before it
reaches the second colluding peer. CVS has been updated to include
this defense, though I very, very much doubt its a practical threat
given the current network size, so I'm not pushing it out as a
release by itself.
This doesn't affect the viability of other timing or shaping attacks
however, but its best to clear up the easy to handle attacks when we
see 'em.
* 3) SSU MACs
As described in the spec [3], the SSU transport uses a MAC for each
datagram transmitted. This is in addition to the verification hash
sent with each I2NP message (as well as the end to end verification
hashes on client messages). Right now, the spec and the code uses a
truncated HMAC-SHA256 - transmitting and verifying only the first
16 bytes of the MAC. This is *cough* a bit wasteful, as the HMAC
uses the SHA256 hash twice in its operation, each time running with
a 32 byte hash, and recent profiling of the SSU transport suggests
this is near the critical path for CPU load. As such, I've done a
little exploring with replacing HMAC-SHA256-128 with a plain
HMAC-MD5(-128) - while MD5 is clearly not as strong as SHA256, we're
truncating the SHA256 down to the same size as MD5 anyway so the
amount of brute force required for collision is the same (2^64
attempts). I'm playing around with it at the moment and the speedup
is substantial (getting more than 3x the HMAC throughput on 2KB
packets than with SHA256), so perhaps we may go live with that
instead. Or if someone can come up with a great reason not to (or
a better alternative), its simple enough to switch out (just one
line of code).
[3]<a rel="nofollow" href="http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html?rev=HEAD">http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html?rev=HEAD</a>
* 4) ???
Thats about it for the moment, and as always, feel free to post up
your thoughts and concerns whenever. CVS HEAD is now buildable
again for those without junit installed (for the moment I've pulled
the tests out of i2p.jar, but still runnable with the test ant
target), and I expect there'll be more news about 0.6 testing fairly
soon (I'm still battling with the oddities of the colo box at the
moment - telnetting to my own interfaces fail locally (with no
useful errno), work remotely, all without any iptables or other
filters. joy). I still don't have net access @ home, so won't be
around for a meeting tonight, but perhaps next week.
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCyr3uWYfZ3rPnHH0RAjwFAJ4pZ+icnR8MioHxrCjVPfFG2a/9KgCdEQBc
p1RmRcbFNI8vA+qVwFGVFT4=
=HJHn
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/07/05/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-07-05
===============================
.. raw:: html
:file: blog/2005/07/05/status.html

98
i2p2www/blog/2005/07/12/status.html Normal file
View File

@@ -0,0 +1,98 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, its that time of the week again
* Index
1) squid/www/cvs/dev.i2p restored
2) SSU testing
3) I2CP crypto
4) ???
* 1) squid/www/cvs/dev.i2p restored
After bashing my head on several colo boxes, some of the old services
have been restored - squid.i2p (one of the two default outproxies),
www.i2p (a secure pointer to www.i2p.net), dev.i2p (a secure
pointer to dev.i2p.net, where the mailing list archives, cvsweb, and
default netDb seeds are found), and cvs.i2p (a secure pointer to our
CVS server - cvs.i2p.net:2401). My blog is still awol, but its
content was lost anyway so there'll need to be a fresh start sooner
or later. Now that these services are back online reliably, its
time to move on to the...
* 2) SSU testing
As mentioned in that little yellow box on everyone's router console,
we've begun the next round of live network testing for SSU. The
tests are not for everyone, but if you're adventurous and are
comfortable doing some manual configuration, check out the details
referenced on your router console (<a rel="nofollow" href="http://localhost:7657/index.jsp">http://localhost:7657/index.jsp</a>).
There may be several rounds of testing, but I don't forsee any major
changes to SSU prior to the 0.6 release (0.6.1 will add support for
those who cannot forward their ports or otherwise receive inbound
UDP connections).
* 3) I2CP crypto
While working over the new introductory docs again, I'm having a bit
of trouble justifying the additional layer of encryption done within
the I2CP SDK. The original intent of the I2CP crypto layer was to
provide a baseline end to end protection of the messages transmitted,
as well as to allow I2CP clients (aka I2PTunnel, the SAM bridge,
I2Phex, azneti2p, etc) to communicate through untrusted routers. As
the implementation progressed however, the I2CP layer's end to end
protection has become redundant, as all client messages are end to
end encrypted inside garlic messages by the router, bundling the
sender's leaseSet and sometimes a delivery status message. This
garlic layer already provides end to end encryption from the sender's
router to the receiver's router - the only difference is that it
doesn't protect against that router itself being hostile.
Looking at the forseable use cases however, I can't seem to come up
with a valid scenario where the local router wouldn't be trusted.
At the very least, the I2CP crypto only hides the content of the
message transmitted from the router - the router still needs to know
to what destination it should be sent. If necessary, we can add an
SSH/SSL I2CP listener to allow the I2CP client and the router to
operate on separate machines, or people who need such situations can
use existing tunnelling tools.
Just to reiterate the crypto layering used right now, we have:
* I2CP's end to end ElGamal/AES+SessionTag layer, encrypting from
the sender's destination to the recipient's destination.
* The router's end to end garlic encryption layer
(ElGamal/AES+SessionTag), encrypting from the sender's router to
the recipient's router.
* The tunnel encryption layer for both the inbound and outbound
tunnels at the hops along each (but not between the outbound
endpoint and the inbound gateway).
* The transport encryption layer between each router.
I want to be fairly cautious about dropping one of those layers, but
I don't want to waste our resources doing unnecessary work. What
I'm proposing is dropping that first I2CP encryption layer (but
still of course keeping the authentication used during I2CP session
establishment, leaseSet authorization, and sender authentication).
Can anyone come up with a reason why we should keep it?
* 4) ???
Thats about it for the moment, but lots going on as always. Still
no meeting this week, but if someone has something to bring up,
please don't hesitate to post it on the list or on the forum. Also,
while I do read the scrollback in #i2p, general questions or
concerns should be sent to the list instead so that more people can
participate in the discussion.
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFC0//0WYfZ3rPnHH0RAs5TAJ9I+yigdzSY8SnLOZS+fNSJ1s/WpwCffzxH
gB0FYFO3bKRemtBoB1JNyLM=
=Qbug
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/07/12/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-07-12
===============================
.. raw:: html
:file: blog/2005/07/12/status.html

40
i2p2www/blog/2005/07/19/status.html Normal file
View File

@@ -0,0 +1,40 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi y'all, brief update this week
* Index
1) SSU testing progress
2) ???
* 1) SSU testing
We've been doing lots of tweaking and bugfixing since this second round
of SSU testing started, but its looking more and more positive. There
are around 20-30 people participating in the tests (or at least running
SSU-enabled routers), and the performance is much better than I had hoped.
There are still some bugs being tracked down, but we're getting close to
the point where we can push 'er out into 0.6 to get full network testing.
The current CVS head is 0.5.0.7-16, though by the time you read this it
may have increased again, so please pull from CVS if you're testing. If
you're holding off until the 0.6 release, have patience ;)
* 2) ???
Thats it for the moment, and yeah, still no meeting this week (though
there's a chance that they'll be back in two weeks or so... not sure
yet). As always, if someone has something to bring up, please don't
hesitate to post it on the list or on the forum.
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFC3TflWYfZ3rPnHH0RAmS/AJ91Vsys+4Sg5uPRz1g0v5uVsl75QgCdGKlB
Toa8+cur8F8ErP5Wz57GeCs=
=yvGt
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/07/19/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-07-19
===============================
.. raw:: html
:file: blog/2005/07/19/status.html

44
i2p2www/blog/2005/07/26/status.html Normal file
View File

@@ -0,0 +1,44 @@
<pre>-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi gang, another brief update this week, but with some important stuff
* Index
1) 0.6
2) ???
* 1) 0.6
Things are looking pretty good on the SSU front, and I don't see any
showstoppers which are holding us back from pushing out as 0.6. As
such, we'll be going live with a new 0.6 release later this week -
lets pencil it in for tomorrow (wednesday). The 0.6 rev is NOT going
to be backwards compatible, so we should expect it to be a bit bumpy,
but everyone should upgrade to it as soon as its out. That includes
people already running 0.5.0.7-19 (or later), as I've held off from
committing the switch to a few vars making it incompatible.
Updating will be simple, though people will want to read the instructions
when they come out (especially those who will need to adjust their
firewall/NAT for UDP communication). There are still some long standing
issues we've been trying to track down, but they're not SSU related so
we can fairly safely continue.
* 2) ???
Thats it for the moment, and yeah, still no meeting this week (though
there's a chance that they'll be back in two weeks or so... not sure
yet). As always, if someone has something (*cough*relevent*cough*) to
bring up, please don't hesitate to post it on the list or on the forum.
=jr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFC5mkxWYfZ3rPnHH0RAnyyAJ9BUpKZAC3xhvCemtzbbj0tG8pP8QCeNz1f
ifBDYsYs61vpTg447SJ02Xk=
=fnLC
-----END PGP SIGNATURE-----
</pre>

6
i2p2www/blog/2005/07/26/status.rst Normal file
View File

@@ -0,0 +1,6 @@
===============================
I2P STATUS NOTES FOR 2005-07-26
===============================
.. raw:: html
:file: blog/2005/07/26/status.html

Some files were not shown because too many files have changed in this diff Show More